Threat intel
Meta GitHub breach: what one stolen login reached
An outside group used a stolen Meta employee login to copy code and data on about 1,500 people from GitHub. How these intrusions work and what to check.
Meta began notifying about 1,500 people, most of them US-based employees, on Tuesday, October 13, that their personal information was taken from some of its GitHub repositories. According to the statement Meta gave SecurityWeek, an outside group got in a few weeks earlier using one employee's stolen credentials. Meta says about 99% of what was taken was business data, meaning source code for some of its products, and about 1% was personal data that staff had stored in the repositories against company policy.
Meta's spokesperson said it "was not a vulnerability in any Meta product" and that Meta's internal systems were not breached. Meta has not said which products the code belongs to, what kind of personal data was involved or how the credentials were stolen. Any organisation whose developers reach GitHub with tokens or SSH keys that are not tied to its identity provider is exposed to the same kind of intrusion, and the checks below show whether it has already happened.
What Meta has said, and what it has not
Meta cut off the attackers' access and brought in GitHub and law enforcement. It rotated the secrets it found in the affected repositories, which means the code contained credentials such as API keys or service passwords that the attackers could otherwise reuse. It says it has also strengthened product security against misuse of the stolen code, is working with teams that use GitHub to keep user data out of it, and is adding scanning to catch personal data uploaded by mistake.
The people affected are being offered credit monitoring and dark web monitoring, and Meta is notifying regulators. Based on its investigation with GitHub so far, Meta does not believe the attackers were specifically after its data.
Several outlets repeat a claim that much of the apparent personal data was synthetic or anonymised test data. SecurityWeek attributes that to Meta, but Meta has not said how much of it was real, so treat it as unconfirmed.
How a stolen-credential GitHub intrusion works
Meta has not said which credential was stolen, so this section describes the general pattern rather than Meta's case. GitHub accepts several kinds of credential for one account: the web password plus a two-factor code, a browser session cookie, personal access tokens (PATs, long strings that act as a password for the API and for git over HTTPS), SSH keys, and OAuth tokens held by apps the user has authorised. Only the web login asks for a second factor. A PAT or SSH key copied from a laptop by infostealer malware, or pasted into a script, works on its own until it expires or is revoked.
With any of these, the attacker can do whatever the employee can. On GitHub that usually means cloning every repository the employee can read, including private ones, along with their full commit history. A password or key deleted from the current code is still in an older commit, so a clone gives the attacker every secret ever committed. Personal data copied into a repository as a test fixture or a debugging export travels the same way.
Cloning over git looks like normal developer work, and the git events that record it are not in the audit log's web view, so a bulk clone by a stolen account is easy to miss unless someone pulls those events.
What to do
1. Tie every credential to your identity provider
On GitHub Enterprise Cloud, enforce SAML single sign-on (SSO) for the organisation so access depends on an active account in your identity provider, and require phishing-resistant MFA (passkeys or FIDO2 security keys) there. With SAML enforced, a PAT or SSH key has to be authorised for SSO before it can reach the organisation, and each authorisation is logged as org_credential_authorization.grant. Owners can view and revoke a member's SSO-authorised credentials from that member's entry under People.
2. Restrict and review tokens and keys
Under the organisation's Personal access tokens settings, block classic PATs, which then get a 403 response, and require approval for fine-grained tokens. Fine-grained tokens can be limited to named repositories and given an expiry date. Then list what already exists: SSH keys and deploy keys, OAuth apps with organisation access and installed GitHub Apps. Remove anything nobody can account for, and any credential belonging to someone who has left.
3. Check whether it already happened to you
Search the organisation audit log for these actions, filtered by the account you suspect with actor:USERNAME:
repo.download_zip, a source archive downloaded as a ZIP fileorg.add_member,repo.add_memberandorg.update_member, someone joining, being added to a repository or promoted to ownerpublic_key.create, a new SSH or deploy keypersonal_access_token.access_granted,integration_installation.createandorg.oauth_app_access_approved, new tokens and apps getting accessrepo.accessandrepo.transfer, a repository made public or moved outhook.create, a new webhook that could forward pushes elsewhere
git.clone and git.fetch do not appear in the web view. On Enterprise Cloud, call GET /orgs/{org}/audit-log with include=git and a phrase such as action:git.clone, using a classic token with read:audit_log. GitHub keeps git events for only seven days, so stream the audit log to your security information and event management (SIEM) system if you want them later. A single account cloning dozens of repositories in an hour is the pattern to look for.
If you know which token leaked, hash it with echo -n TOKEN | openssl dgst -sha256 -binary | base64 and search for hashed_token:"VALUE" to see everything that token did.
4. Stop secrets and personal data reaching repositories
Turn on secret scanning and push protection for every repository. Push protection blocks a push that contains a recognised secret, and the bypass list (org_secret_scanning_push_protection_bypass_list.add in the log) should stay short. Personal data belongs in a separate store with its own access controls. Use generated test data, and add a custom secret scanning pattern for identifiers like your employee ID format.
5. If code was taken, rotate what was in it
Search the full history of every exposed repository for credentials, not only the current branch, and rotate each one at the system that issued it. Deleting a key from the code does not help once a copy exists outside.
The wider lesson
Multi-factor authentication protects the web login, not the tokens and keys a developer has already created. A long-lived PAT on a developer laptop gives an attacker the same access as the employee, and nobody is asked for a second factor when it is used. Treating GitHub tokens and keys like service account passwords, with expiry, scope, an owner and a log, makes a stolen credential much less useful.
Our safeguarding and hardening work covers GitHub organisation settings, token policy and secret scanning, and our security operations team can stream and watch your GitHub audit log. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.
Sources: SecurityWeek, GBHackers, Digit, GitHub Docs: audit log events for your organization, GitHub Docs: security incident investigation areas, GitHub Docs: identifying events by access token, GitHub Docs: personal access token policy, GitHub REST API: organization audit log.