On 13 October 2026, Meta began notifying about 1,500 people, most of them US employees, that an outside group had used one employee's stolen credentials to access some of its GitHub repositories. Meta told SecurityWeek that 99% of what was taken was business data, software code related to some of its products. The remaining 1% was personal data that had been placed in the repositories by mistake, against company policy.
The entry point was a login, not a software flaw. As a Meta spokesperson put it: "This was not a vulnerability in any Meta product, and Meta's internal systems were not breached."
What's affected
From Meta's statements as reported by SecurityWeek:
- Access path: An outside group used an employee's stolen credentials to reach some of Meta's GitHub repositories. Meta has not said how the credentials were stolen.
- Detection: A few weeks before notifications began.
- Data taken: About 99% business data, namely source code for some products. About 1% personal data.
- Personal data: Added to the repositories by mistake. Meta says much of what looked like personal data was synthetic or anonymized test data. It has not said which types of personal data were involved.
- People notified: About 1,500, mostly US employees, offered credit and dark web monitoring. Meta says it is also notifying regulators.
- Motive: Based on its investigation with GitHub, Meta does not believe the attackers were specifically targeting its data.
- Response: Meta cut off the attackers' access, brought in GitHub and law enforcement, rotated secrets found in the affected repositories, and hardened product security against risks from the exposed business data. It is working with teams that use GitHub to keep user data off the platform and adding proactive scanning to catch user data uploaded by mistake.
How to check if you're exposed
There is no indication that Meta's code release affects other organizations' software. The useful check is whether your own GitHub organization would let one stolen login do the same.
- Find members without two-factor authentication.
gh api "orgs/YOUR_ORG/members?filter=2fa_disabled" --paginate --jq '.[].login'
- List tokens and SSH keys authorized for SSO. On organizations using SAML SSO, this shows personal access tokens and keys with access, and when they were last used:
gh api orgs/YOUR_ORG/credential-authorizations --paginate \
--jq '.[] | [.login, .credential_type, .credential_authorized_at, .credential_accessed_at] | @tsv'
- Look for bulk clone activity. On plans with Git events in the audit log, query clones and look for one account touching many repositories in a short window:
gh api "orgs/YOUR_ORG/audit-log?phrase=action:git.clone&include=git&per_page=100" \
--jq '.[] | [.actor, .repo, .created_at] | @tsv'
- Scan repositories for secrets and personal data. Meta says it rotated secrets found in the affected repositories. Run a secrets scanner across all branches and history, and add simple patterns for personal identifiers:
gitleaks detect --source . --log-opts="--all"
git grep -nE '\b[0-9]{3}-[0-9]{2}-[0-9]{4}\b' $(git rev-list --all) | head
What to do now
- Enforce SSO and phishing-resistant MFA for GitHub. A stolen password should not be enough. Require security keys or passkeys for anyone with access to private repositories.
- Restrict personal access tokens. Require fine-grained tokens with expiry and admin approval, and limit or block classic tokens at the organization level.
- Scope repository access by team. An employee should see the repositories their work needs, not the whole organization. Review base permissions and broad team grants.
- Turn on secret scanning with push protection. Stop new secrets entering repositories, and alert on existing ones.
- Keep personal data out of source control. Meta is adding proactive scanning for this. Add a pre-commit or CI check for common personal data patterns, and use synthetic fixtures for tests.
- Stream the audit log off GitHub. Send it to your SIEM and alert on unusual clone volume per user.
- Plan for code exposure. Assume private code may leak one day. Make sure it holds no credentials and that security does not rely on the code staying secret.
Why it matters
Source code repositories are part of your software supply chain. They hold the code you ship, the CI configuration that builds it and often secrets that reach production. A single developer login can expose all of it if repository access is broad and tokens are long-lived.
Meta's account is also a useful reminder that personal data ends up in places it should not. Test fixtures, debugging dumps and exported datasets make their way into repositories, and then a code breach becomes a personal data breach with notification duties.
Try it yourself
Run the two-factor and credential authorization commands above against your GitHub organization. Count members without 2FA, tokens with no expiry and tokens not used in 90 days. Revoke the stale ones and set a date to fix the rest.
Click through it at your own pace, or open it full screen.
Quick check
Was this a vulnerability in GitHub or a Meta product?
Meta says no. An outside group used an employee's stolen credentials. Meta said it was not a vulnerability in any Meta product and its internal systems were not breached.
Why was personal data in the repositories?
Meta says it was added by mistake against company policy, and much of the apparent personal data was synthetic or anonymized test data.
What did Meta do about secrets in the repositories?
It rotated secrets found in the affected repositories and is adding proactive scanning to catch user data uploaded by mistake.
