Breach Debrief: The MyHeritage Breach Nobody Detected for Seven Months

This is the first entry in what I'm calling The Breach Debrief. Periodically here, I'm going to take a real, publicly documented cyber breach, walk the chain of events the way an investigator would, and pull out the lessons - some obvious, some not. No inside information, no speculation dressed up as fact. Just what's actually known, and what it should change about how you operate.

First up: MyHeritage.

What happened

MyHeritage runs a genealogy platform - family trees, historical records, DNA matching, tens of millions of users. In June 2018, the company disclosed that a security researcher had found a file sitting on a private server outside MyHeritage's own infrastructure, containing email addresses and hashed passwords for more than 92 million accounts, close to 95 percent of their user base.

Here's the detail that should stop you: the breach itself happened the previous October. Seven months earlier. MyHeritage didn't find it. A third party did, and told them.

The chain of events, as far as it's known

Intrusion: October 26, 2017. Discovery: June 4, 2018, when a researcher located the file on infrastructure MyHeritage didn't control. Response: an incident response team stood up, outside forensics engaged, regulators notified under GDPR, and multi-factor authentication accelerated across all accounts.

What wasn't compromised, according to the company: the passwords themselves (the file held individually salted hashes), and separately, DNA profiles and family tree data, which sat on segregated systems. What was never determined: how the intrusion actually happened. No public attack vector, no attribution, no name to whoever was behind it.

Lessons, obvious and not

The obvious one first: seven months is not a detection window, it's a blind spot. Cybercrime doesn't need a sophisticated attacker, it needs a path of least resistance, and an unmonitored file sitting on somebody else's server for seven months is about as close to that as it gets. Any incident response plan worth having assumes you'll be the one who finds it, not a researcher doing you a favour.

Second, less obvious: segregation worked here, and that's worth noticing when breach commentary usually only covers what went wrong. The more sensitive data - DNA profiles, family trees, financial details - sat apart from the credentials that were exposed. That's not luck, that's architecture. Design your systems so one compromised store doesn't hand over everything, and a bad day stays a bad day.

Third: an unresolved attack vector is itself a finding. It's tempting to treat "we don't know how they got in" as an embarrassing gap in the story. I'd call it the most honest thing in it. Organizations that quietly guess at a cause to fill the silence make worse decisions afterward than ones that say plainly: we don't know yet, and we're not going to pretend otherwise.

Fourth, and the one I think gets missed most: the data that wasn't stolen mattered as much to the story as the data that was. Genetic and genealogical data raise questions that hashed email credentials don't - who else it identifies without consent, whether it can ever really be "changed" the way a password can. An organization holding that kind of data has to think about exposure differently than one holding logins.

The takeaway

None of this required a sophisticated attacker doing something exotic. It required an organization that didn't find its own breach for seven months, systems designed well enough to contain what did get out, and an industry still working out what "acceptable risk" means for data that can't be reset.

That's usually how it goes. The interesting failures aren't the ones with a clever villain. They're the ones with an ordinary gap that sat open long enough to matter.