Meta Says Hackers Accessed GitHub Repositories Using Stolen Employee Credentials

Meta has disclosed a cybersecurity incident in which an outside group used stolen employee credentials to access some of the company’s GitHub repositories, exposing software source code and a limited amount of personal information. The company is notifying approximately 1,500 people whose personal information may have been involved, most of whom are Meta employees in the United States. Meta detected the intrusion several weeks before publicly discussing the incident in October 2026.

The company says the attackers accessed business data stored on GitHub rather than breaching Meta’s internal systems directly. According to information Meta shared with SecurityWeek, approximately 99% of the stolen material consisted of business information and product-related source code, while the remaining 1% was personal information. Meta says some of the personal data had been uploaded to repositories by mistake, contrary to its internal policies. The company has blocked the attackers’ access and is working with GitHub and law enforcement to investigate.

Key Takeaways

• Hackers used stolen employee credentials to access some of Meta’s GitHub repositories.
• Approximately 1,500 people may have had personal information exposed, mostly US-based Meta employees.
• Meta said around 99% of the stolen material was business data and software source code, with approximately 1% consisting of personal information.
• A significant portion of the apparent personal records was synthetic or anonymised test data, according to Meta.
• The company says its internal systems were not breached and the incident did not involve a vulnerability in a Meta product.
• Meta has rotated secrets found in the affected repositories, strengthened security controls and begun offering affected individuals credit and dark-web monitoring.

What Happened in the Meta GitHub Breach?

The incident involved unauthorised access to some of Meta’s repositories hosted on GitHub, a platform developers use to store, manage and collaborate on software projects.

According to Meta’s account, an outside group obtained an employee’s credentials and used them to enter the repositories. The company has not publicly explained exactly how the credentials were stolen or identified the attackers.

The distinction matters because attackers do not always need to exploit a software vulnerability to access sensitive information. If they obtain legitimate login credentials, they may be able to operate through an account that already has permission to view company resources.

Meta said it discovered the intrusion several weeks before the October 13–14 reporting. After identifying the incident, its security team cut off the attackers’ access and began working with GitHub and law enforcement.

The company has not disclosed the exact number of repositories accessed, the full list of affected products or whether the attackers published the stolen code. It has also not publicly established whether the compromised employee account was protected by multi-factor authentication.

Those unanswered questions limit what can be concluded about the incident’s technical scope. Access to a repository can expose source code and other stored information, but the precise consequences depend on what the repositories contain, which permissions the account has and whether other systems can be reached using credentials found in the code.

What Information Was Exposed?

Meta told SecurityWeek that approximately 99% of the stolen material was business information, including source code associated with some of its products. The remaining approximately 1% was personal information involving a limited number of people.

The company is notifying around 1,500 people whose personal information may have been affected. Most are employees based in the United States.

Meta has not publicly provided a complete list of the personal information involved. It is therefore not possible to determine from the available disclosures whether every affected individual faces the same level of risk.

The company has also said that a significant portion of the records that appeared to contain personal information was actually synthetic or anonymised test data. Developers commonly use such records to test applications without relying on real people’s information.

Synthetic data can reduce privacy risks, but its presence does not mean every exposed record is harmless. Investigators still need to distinguish genuine personal information from test records and assess whether the data could be linked to actual individuals.

Meta’s explanation also raises an important data-governance issue: personal information was present in repositories where company policy prohibited storing it. Even if the information was included accidentally, its presence increased the potential impact of the unauthorised access.

The company has not publicly identified the precise data fields involved, so claims about exposed passwords, payment information, government identification numbers or other specific personal details should not be treated as confirmed.

Did Hackers Breach Meta’s Internal Systems?

Meta says its internal systems were not breached and that the incident was not caused by a vulnerability in a Meta product.

Instead, the company described the incident as unauthorised access to business data held in GitHub repositories using stolen employee credentials.

This distinction helps explain the reported scope, but it should not be interpreted as meaning the incident was inconsequential. A repository can contain commercially sensitive source code, configuration information and credentials that developers use to connect software with other services.

Source code may reveal how an application is structured, how certain functions operate and where security checks are implemented. Depending on the contents, attackers could potentially use that knowledge to identify weaknesses or develop more targeted attacks. However, Meta has not confirmed that the stolen code has been used in any subsequent attack.

The risk also depends on whether repositories contained active secrets, such as API keys, access tokens or other credentials. Meta says it rotated secrets found in the affected repositories, a step intended to invalidate exposed credentials and reduce the possibility of further unauthorised access.

The available information does not establish that the attackers gained access to Meta’s wider corporate infrastructure, customer accounts or production systems. Such claims would go beyond the company’s disclosures.

Why Stolen Employee Credentials Are a Serious Security Risk

Employee credentials are valuable targets because they can provide access through approved authentication systems rather than requiring attackers to break through a technical vulnerability.

A compromised account may inherit the permissions assigned to its legitimate owner. If that account can access private repositories, an attacker may be able to inspect or copy files without triggering the same warning signs associated with an unfamiliar software exploit.

The potential damage depends on several factors: the employee’s access privileges, the security controls protecting the account, the repositories available to it and the monitoring systems that record account activity.

Multi-factor authentication can make stolen passwords less useful by requiring an additional verification step. However, it is not a complete defence against every form of account compromise, particularly if attackers obtain session tokens or find other ways to bypass authentication protections.

Organisations can reduce the impact of compromised accounts by limiting repository permissions, monitoring unusual downloads and account activity, reviewing access tokens and regularly scanning repositories for accidentally exposed secrets or personal information.

GitHub’s security documentation recommends investigating compromised credentials, reviewing audit logs and examining suspicious repository activity as part of incident response. These controls can help organisations establish what an account accessed and whether any unauthorised changes were made.

The Meta incident illustrates why companies need to treat developer accounts and source-code platforms as important parts of their security perimeter, even when those platforms are separate from their internal corporate systems.

Meta’s Response and New Security Measures

Meta says it has taken several steps since discovering the intrusion.

Blocking the attackers: The company says it shut down the unauthorised access and involved GitHub’s security team and law enforcement in the investigation.

Rotating exposed secrets: Meta has replaced secrets found in the affected repositories. This is important because a key or token may remain usable even after the original access route has been closed.

Strengthening repository protections: The company says it has worked with GitHub on additional measures to protect its repositories and has strengthened product security to address risks arising from the stolen source code.

Preventing accidental data storage: Meta says it has introduced new controls to prevent personal information from being stored in GitHub repositories, along with proactive scanning intended to detect such information when it is uploaded by mistake.

Notifying affected individuals: Meta has started contacting people whose personal information may have been involved. It is also offering credit monitoring and dark-web monitoring services to those affected.

These actions address different parts of the incident. Blocking access limits immediate intrusion, rotating secrets reduces the usefulness of exposed credentials, and scanning can help prevent sensitive information from entering repositories in the future.

The effectiveness of the measures will depend on their implementation and on the findings of the ongoing investigation. Meta has not disclosed enough technical detail to independently assess the full scope of the remediation.

Why the Incident Matters for the Technology Industry

The breach highlights a security challenge shared by companies that develop software at scale: code repositories often sit at the intersection of engineering work, access credentials, internal documentation and product development.

A repository may be intended primarily for source code but can accumulate other material over time. Test data, configuration files, debug output and credentials can be committed accidentally unless preventive controls catch them.

The consequences can extend beyond privacy. Stolen source code could provide an attacker with insight into how a product works, while exposed secrets could create additional avenues for unauthorised access if they remain active. The actual risk depends on the material taken and whether any credentials were usable.

The incident also shows why companies need to distinguish between a direct breach of their own infrastructure and unauthorised access to a third-party platform holding their data. The hosting platform may operate normally while an attacker uses a compromised company account to access private resources.

For businesses, the lesson is not simply to secure passwords. It is to reduce the amount of sensitive information stored in development environments, apply least-privilege access, use multi-factor authentication, monitor repository activity and scan for secrets and personal data before and after code is committed.

What Happens Next?

Meta’s investigation with GitHub and law enforcement will help determine how the employee credentials were compromised, what information was accessed and whether any additional systems or credentials were affected. The company has not publicly identified the attackers or provided a complete technical account of the incident. Further details may emerge as the investigation progresses.

For now, Meta says it has contained the access, rotated secrets found in the repositories and begun notifying affected individuals. The incident underscores the importance of protecting source-code platforms and preventing personal information from entering development repositories. Until Meta discloses more details, the full impact of the stolen source code and the specific risks to affected individuals remain uncertain.

Frequently Asked Questions

1. How did hackers access Meta’s GitHub repositories?

Meta says an outside group used stolen employee credentials to access some of its repositories. The company has not publicly explained how the credentials were obtained.

2. How many people were affected by the Meta breach?

Approximately 1,500 people may have had personal information exposed, most of them Meta employees based in the United States. Meta has not publicly detailed every type of personal information involved.

3. Was Facebook or Instagram directly hacked?

Meta says its internal systems were not breached and that the incident was not caused by a vulnerability in a Meta product. The reported access involved business data stored in GitHub repositories. The company has not reported that the incident directly compromised Facebook or Instagram user accounts.

4. What is Meta doing after the breach?

Meta says it has blocked the attackers’ access, rotated secrets found in the affected repositories, introduced controls to prevent personal data from being stored in GitHub, strengthened security and is offering credit and dark-web monitoring to affected individuals.