Meta GitHub breach: why personal data ended up in a code repo

Meta is notifying roughly 1,500 people, most of them US employees, that their personal information was taken in a breach of some of the company's GitHub repositories. According to SecurityWeek, an outside group got in using one employee's stolen credentials. Meta detected the intrusion a few weeks ago and shut off the attackers' access before bringing in GitHub and law enforcement.

Meta told SecurityWeek that 99% of what the attackers took was business data, mostly source code. The remaining 1% was personal data that had been added to the repositories by mistake. Storing it there went against company policy.

That last detail is the one most security leaders will recognize.

Meta hasn't said what types of personal information were involved or how they got into the repositories. It did tell SecurityWeek that a significant portion of what looked like personal data was synthetic or anonymized test data.

The pattern is familiar. A developer needs realistic records to test a feature. Someone exports a sample from production and commits it to a fixtures folder. It works, so it stays. Months later the repository holds files nobody thinks of as sensitive, because a repository is "just code."

Credentials drift the same way. Meta said it rotated secrets found in the affected repositories as part of its response.

Meta had the right rule. Personal data wasn't supposed to live in GitHub. The rule had no way to see what developers were actually committing.

Policies describe where data should live. They can't report where it went. In many organizations code repositories sit outside the scope of data discovery altogether. Teams scan code for vulnerabilities and leaked keys, while employee records sitting in a test file rarely trigger anything.

That leaves identity as the only control between an attacker and the data. Once an employee's credentials were stolen, everything those credentials could reach was exposed. That included records nobody knew were there.

Meta told SecurityWeek it's working with the teams that use GitHub to keep user data off the platform. As a second line of defense, it's adding controls for proactive scanning to catch user data uploaded by mistake.

Meta's fix is a sound one. It also doubles as a checklist for anyone else running code in GitHub:

1. Do you know whether your repositories hold personal, regulated or any other sensitive data right now?
2. Would you find out if a developer committed a production export tomorrow?
3. If one engineer's credentials were stolen today, what sensitive data could they reach?

If the honest answer to any of those is "we'd find out from an attacker," the gap is visibility.

MIND connects to GitHub alongside the other SaaS apps where your data lives. It classifies files by content and context, so a file of employee records in a fixtures folder gets flagged for what it is. Sitting in a code repository doesn't make it invisible. And MIND is smart enough to see the difference between test data and the real, sensitive thing.

When MIND finds sensitive data where it shouldn't be, it explains the risk and escalates it to the owner. Your team gets a finding with the file and the repository attached, along with the person who can fix it. Nobody has to write a regex for every data type a developer might paste into a test.

Underneath the classification, MIND is closing the distance between the policy you wrote and what actually gets committed. The goal is to find those files before anyone else does.

“MIND allows us to see and protect our data across every vector, endpoints and SaaS, from a single place. It's like having a spotlight that shines where visibility didn't exist before.”

Meta is adding repository scanning after an incident. You can run the same check before one happens to you. Book a demo and see what MIND finds in your GitHub repositories and SaaS apps within 24 hours. That's DLP on Autopilot, starting with the data you didn't know you had.

Let's mind what matters.