Meta's GitHub Breach: A Repository Holds More Than Code

As of October 15, 2026.

A repository is a data store, and anyone who can read it can take all of it. Meta's breach, disclosed on October 13, came down to one employee's stolen credentials and the files a repository held. Some of those files were code, some were secrets, and some were personal data that company policy said should never have been there.

What Meta has said

We found no post from Meta about the incident. The public record is a Meta statement to SecurityWeek on October 13. The spokesperson said:

This was not a vulnerability in any Meta product, and Meta's internal systems were not breached. Meta business data held in a GitHub repository was improperly accessed using an employee's stolen credentials—this included a small amount of personal data for a limited number of people, most of whom were Meta employees.

SecurityWeek adds the rest, attributed to Meta:

• An outside group got in with the stolen credentials, and Meta detected the intrusion a few weeks before disclosure. Its security team cut off the access and brought in GitHub and law enforcement.
• Meta told SecurityWeek that 99% of the data taken was business data, software code related to some of its products. The other 1% was personal data, added to the repositories by mistake and against company policy.
• Meta said a significant portion of what looked like personal data was synthetic or anonymized test data.
• About 1,500 people, most of them US-based Meta employees, are being notified, starting October 13, with credit and dark web monitoring offered. Meta is also notifying regulators and has not said what types of personal data were involved.
• Based on its investigation with GitHub so far, Meta does not believe the attackers were specifically after its data.

Meta has not said how the credentials were stolen, which repositories were involved, or whether the account was on github.com or a GitHub Enterprise instance. This post does not guess.

What the response tells you

The fixes Meta described are the useful part. "We've since rotated secrets found in the repositories, implemented new controls to prevent user data from being stored in GitHub, and worked with GitHub on additional measures to protect our repositories," the spokesperson said.

The first clause says the repositories held secrets. The second says personal data had reached them despite a policy against it. Neither problem was in the code, and the stolen credential reached both without any further break-in.

Meta's line that its "internal systems were not breached" can be true and still miss the point for defenders. Whatever a repository contains is readable by every credential with read access, so the repository's real sensitivity is the most sensitive file in it, including its history.

The synthetic data cuts both ways. It limits harm to the people involved. It also means the attacker may not be able to tell real records from fake ones, as SecurityWeek notes, and neither can a defender sorting out whom to notify without a record of which fixtures were real.

What to do now

1. Know what one credential can read. For each engineer, list the repositories their account and tokens reach. Prefer fine-grained, expiring tokens scoped to the repositories a task needs, and require SSO for organization access.
2. Scan repositories and history for secrets. A key deleted from the tip is still in the history a clone carries. GitHub's built-in scanning misses some of this, so run your own scanner across full history.
3. Look for personal data as well as keys. Search for exports, database dumps, CSVs and test fixtures built from production records. Mark synthetic data as synthetic in the file or path, so you can prove which records were real if you ever have to.
4. Write the repository-access runbook before you need it. If a credential with read access is stolen, assume every file it could read, in every branch and commit, is gone. Rotate every secret in those repositories, then follow your leaked key response for each one.
5. Watch for bulk reads. Large clones or archive downloads by one account in a short window are the signal here. Check what your GitHub plan records in its audit log and make sure someone receives those events.
6. Stop new secrets at the commit. A pre-commit hook is cheaper than a rotation after a breach.

Where Rafter fits

Rafter cannot tell you whose credentials were stolen or what a token can read. It covers part of steps 2 and 6: rafter secrets . scans a working tree for secrets locally with no account, and rafter agent install-hook adds a commit hook that blocks new ones. It does not detect personal data, so step 3 needs its own search.