Mailgun: Public Security Disclosure

TLDR: Inbound email routes don't have SPF/DKIM/DMARC protection, meaning any inbound email sent to a webhook can be trivially spoofed / phished. Mailgun describe inbound routes as:

"complex incoming messages are simplified and parsed into all of the data you need with Inbound Routes." [1]

Mailgun refers to DKIM/SPF/DMARC with:

"Mailgun leads the charge in email authentication by requiring DKIM and SPF records by default before you can begin sending." [2]

However, nowhere does it say that Mailgun does not provide SPF or DKIM validation checks on inbound emails. Confusingly, these headers appear only for a subset of inbound emails.

Attack scenario:

1) Pick any domain using mailgun for inbound email processing (trivially found via MX records).

2) Spoof an email from any address you want to impersonate (eg. security@mailgun.com).

If that address is handled via an inbound route to a webhook (eg. CRM system / other), then it will appear as from the spoofed sender without any DKIM/SPF flags. This makes phishing via Inbound Routes trivial.

Requested fix:

Include SPF (X-Mailgun-Spf), DKIM (X-Mailgun-Dkim-Check-Result), and Spam Assassin headers (eg. DMARC_QUAR / DMARC_REJECT / DMARC_NONE / DMARC_MISSING) headers for ALL inbound routes to a webhook. The application can then decide what to do.

Mailgun Response:

"Our security team has confirmed that our routes act as an open relay and that this is not considered a security vulnerability with Mailgun."

Nowhere in the Mailgun documentation / sales pages are inbound routes described like this, and in fact, they pretend to have protection as headers are sometimes present!

Note A: Using throwaway to not give information away for our own exposed systems.

Note B: The spoofed email must not trigger above a certain spam assassin threshold (this is fairly trivial to do and openly testable by any attacker), otherwise it might get blocked by higher level Mailgun spam handling.

[1] - https://www.mailgun.com/products/send/inbound-routing/

[2] - https://www.mailgun.com/blog/deliverability/implement-dmarc/...

Yes - it's emails that hit a certain pre-determined spam assassin threshold (see Note B). But this is fairly easy to circumvent (spammers/phishers are especially good at it) and the threshold is reasonably high.

All in all this means the vast majority of emails don't have these headers included in webhooks, and we have plenty of examples of spoofed emails for our own domain (invalid SPF/DKIM and failed DMARC) that get through without triggering spam assassin.

This simplest way to verify this is to store the value of these headers along with all inbound emails hitting your webhooks, you'll quickly see they are missing the majority of the time.

If I'm reading this right, the recipient has to be a mailgun user, and the sender has to be another (yet spoofed) mailgun user.

The sender can be anyone. They don't need to be a mailgun user.

The recipient has to be a mailgun user, yes.

Do you know if they verify the sender for ARF (abuse) emails that should be coming from the recipient's hosting provider e.g. yahoo. If not this could potentially be used for targeted denial of service by submitting fake spam reports on behalf of other recipients to add them to the suppression list?