See D19952. This is like a 9 on the 🙄 scale, but you can attack Phabricator locally like this:

• Add alice@yourcompany.com as an inbound task email. This is the address for a real user at your company.
• Trick someone into using "Reply All" on a thread which Alice is part of, including some address which routes to Phabricator as a "To" or "Cc".
• The message is processed for the alice@yourcompany.com recipient even though this recipient is not routable to Phabricator, because some other recipient is routable to Phabricator and we can't tell which recipients caused routing.
• The message is converted into a task which the attacker can see, even if they were not on the original thread and can not see the object it references.

When Phabricator receives the mail, it doesn't know which "To" or "Cc" actually caused delivery, so it evaluates every address as a possible target. This includes addresses which may be both valid user addresses and valid application email addresses.

Performing this "attack" requires administrator privileges and probably some weird social engineering around making the "Reply All" happen.

To fix this, you shouldn't be able to add any user address as an application email address ("This address is already in use by a user."), and if a user later adds an application email address to their account, it should disable new processing to that address ("This address is now associated with a user account, and no longer valid.").