Meta began notifying around 1,500 people this week that attackers got into some of its GitHub repositories using a single employee's stolen credentials, according to SecurityWeek's report. Meta says the intrusion was spotted several weeks ago, that it cut off access, and that GitHub and law enforcement were brought in. Most of the people notified are US employees.
What was taken
Meta's own split is 99% business data, mainly software code tied to some of its products, and 1% personal data. The company is blunt about the second part: that information was in the repositories by mistake, against internal rules that say it should not be on GitHub at all. It adds that a large share of what looked like personal data was synthetic or anonymised test data. It has not said which products the code belongs to, what categories of personal information were involved, or whether anything was changed or published. Coverage such as Cyber Security News notes that how the credentials were stolen has not been explained and no group has been named. Meta says its investigation with GitHub so far suggests the attackers were not specifically after Meta's data, and that this was not a flaw in a Meta product and its internal systems were not breached.
The part worth sitting with
Read that last claim carefully, because it is true and it does not help much. If the attackers were not targeting Meta, then Meta was reached because a login was valid and a repository was reachable with it. That is exactly how it looks from the inside of any company: a developer account is a key to a building where nobody counted the rooms.
The rule that personal data does not belong in source control is also one that every engineering organisation has written down and every engineering organisation has broken. A test fixture copied from production, a CSV committed to debug a bug on a Friday, a config file with a real customer's email in it. A policy cannot stop that. A scanner can find it, and Meta says it is adding exactly that kind of proactive scanning now, along with rotating the secrets it found in the affected repositories.
What we would check this week
- How many people can read your most sensitive repositories, and how many of them have used that access in the last 90 days? The gap is usually large.
- Whether GitHub (or GitLab, or Bitbucket) sign-in demands phishing-resistant MFA through single sign-on, with personal access tokens that expire and are tied to the organisation.
- Run a secret and personal-data scan across the whole history, not just the default branch. Old commits are where the surprises are.
- Where repositories contain test data, find out whether it is synthetic. "Anonymised" is a claim that deserves a sample check.
- Alert on unusual cloning: a login that pulls dozens of repositories at 03:00 should reach a person before it finishes.
- Decide in advance which secrets get rotated first if a repository is copied. If the answer is "all of them", the rotation process needs rehearsal.
This follows a run of incidents where the entry point was a developer or contributor identity and not a clever exploit. If you want a second pair of eyes on your repository estate, write to sales@halfteck.com.