Attackers Walked Into Meta's GitHub With Stolen Employee Credentials
Attackers used stolen employee credentials to access Meta's GitHub repositories and take source code. Here's what happened, and what every team should learn from it.
What actually happened
Meta disclosed on October 13 that attackers had accessed some of its GitHub repositories using stolen employee credentials. The company said it detected the intrusion several weeks before the disclosure, cut off the attackers' access, and brought in GitHub and law enforcement.
About 99% of what was taken was business data, mostly software source code related to Meta products. The remaining 1% was personal information concerning roughly 1,500 people, mostly US-based Meta employees. Meta said it had mistakenly placed personal information in the repositories despite company rules prohibiting it, and that a significant portion of the apparent personal records was synthetic or anonymized test data.
Meta was careful about what the breach was not. It said the incident was not caused by a vulnerability in any Meta product, and that Meta's internal systems were not breached. Only the GitHub repositories were affected. The attackers have not been identified, and Meta has not said how the credentials were stolen or whether multi-factor authentication was in place.
Why source code theft matters
When people hear "breach," they usually think of passwords and credit cards. Source code sounds less alarming. It is not harmless.
Stolen code lets attackers study a product's internals at leisure: how authentication works, where the edge cases are, which third-party components are bundled in. That knowledge can turn into future vulnerabilities, especially in widely used libraries or services. It can also feed competitors and counterfeiters. For a company the size of Meta, the practical damage is likely contained, but the principle is uncomfortable: the code that runs products used by billions of people was in someone else's hands.
The personal data is the sharper problem. Fifteen hundred people is small by breach standards, but these were employees whose information was not supposed to be in those repositories at all. Rules prohibiting personal data on GitHub existed; they were not followed. That gap between policy and practice is the story of most breaches.
The credential problem
The Meta GitHub breach is, at its core, a stolen-credential story. No zero-day, no exotic exploit: someone got hold of login credentials that worked, and used them. This is the most common way serious breaches start, and it is why the October breach wave keeps repeating the same five mistakes.
The unanswered question is whether multi-factor authentication was enabled on the compromised account. Meta has not said. If it was not, that is a basic failure at one of the world's most sophisticated security organizations. If it was and the attackers bypassed it, that is arguably worse news for everyone else, because it means session hijacking or adversary-in-the-middle techniques are working against real targets.
Either way, the lesson for teams is the same: credentials alone cannot be the perimeter. Short-lived tokens, hardware keys, and strict scoping of what any single account can access are what stand between a stolen login and a full repository dump.
What to do if you run a team
Start with an audit of what lives in your repositories. Secrets, personal data, and internal credentials drift into code repos constantly, usually because someone was in a hurry. Automated secret scanning catches some of it, but a manual review of what your repos actually contain is worth the afternoon.
Next, check who has access and what they can do with it. A contractor's account from two years ago should not still be able to clone your core repositories. Access reviews are boring and they work.
Then move to passkeys and hardware keys for the accounts that matter most. Phishing-resistant authentication does not stop every attack, but it closes off the most common path: someone typing a stolen password into a real login page.
Finally, assume breach. The WordPress plugin flaw showed attackers exploiting vulnerabilities before disclosure. The Meta case shows attackers walking in with legitimate credentials. Your detection has to cover both: anomalous access patterns, unusual clone volumes, logins from unexpected places. The companies that catch intrusions in weeks, not months, are the ones that watch for those signals.
