When I get spam email, I usually check the headers and if it's coming from a reputable service (Postmark, Sendgrid, etc.) they usually have a web form or an abuse@ email to send the headers to so that they can shut down the account.<p>Months ago I received spam from a Mailgun server and tried to use their web form[1] to report it, but it was broken. I reported both that bug and the spam email to their support, which acknowledged it. Weeks later I got another spam email from that same domain, popped open that report form and it was still broken (FWIW as of today it seems to be working again). So I followed up on my initial support request with that info but got no response. Just a few days ago I received another spam message from that domain.<p>I personally consider all that a very bad sign in an email service provider and wouldn't use Mailgun myself. In contrast, I've been very happy with Postmark.<p>[1]: <a href="https://www.mailgun.com/receiving-spam-from-mailgun" rel="nofollow">https://www.mailgun.com/receiving-spam-from-mailgun</a>
This was used to steal bitcoin cash tips on Reddit by hijacking password reset emails (<a href="https://www.reddit.com/r/bugs/comments/7obxkb/mailgun_security_incident_an_update_on_the_state/" rel="nofollow">https://www.reddit.com/r/bugs/comments/7obxkb/mailgun_securi...</a>)<p>I find it amusing they still have a "trusted by Reddit" blurb on their homepage after this!
Why would employees need access to client API keys, as opposed to just client ID?<p>Furthermore, this seems to indicate that the API keys are not hashed. I would expect some bits of the API key to work as an identifier and the rest of the bits treated as secret material (properly hashed).<p>As a Mailgun customer, this is concerning..
Er, can we expect more information to follow?<p>1. How was the employee's account accessed? No 2FA?<p>2. Do employees ordinarily have access to customer secrets (e.g. API keys) or was there some further exploit?<p>3. The advice in OP for affected customers is to roll keys and SMTP logins. Couldn't/shouldn't you do that for them? Surely security should trump up-time/deliverability?
Does this only affect Mailgun's customers? If these customers hold data of third-party – let's call them "end-users" – in Mailgun accounts, Mailgun could/should communicate the total number of individuals affected. "1% of our customers/users" can affect millions of individuals.
In those security disclosures, I often read what I see as contradictory language.<p>For example, I'm confused by this kind of statement:<p>> Mailgun has now completed its diagnostic of accounts that were affected and has notified each of the affected users. At this time, we believe less than 1% of our customer base was potentially affected. If you were not directly notified by Mailgun regarding this incident, then your account was not affected.<p>If you <i>believe</i> that <i>less than</i> 1% of users were affected, it means you don't know for sure how many accounts were affected.<p>From there, how can you state that "If you were not directly notified by Mailgun regarding this incident, then your account was not affected"?<p>Doesn't this last statement mean you know for sure my account was not affected? Isn't it in direct contradiction with the previous statement?
I like Mailgun so much because of its simplicity but last November 2017 the default postmaster account of one of our domain in Mailgun was hacked. (I don't know where it was hacked but i suspect it was on the Mailgun server because I kept the secret key in my server very well). We moved to Sendgrid because my account in Mailgun got a very bad reputation. One of the hacked smtp credentials was used to send spam.
> At this time, we believe less than 1% of our customer base was potentially affected. If you were not directly notified by Mailgun regarding this incident, then your account was not affected.
> Finally, we’d like to assure our customers and partners that we take security at Mailgun very seriously.<p>So very seriously that they don't even use https for their blog...