# Security Firm Discloses Breach of Private Code Repositories After Supply Chain Attack
A prominent French cybersecurity firm has disclosed that approximately 170 of its private code repositories were copied by an unauthorized party in May, with the sensitive material eventually surfacing on a public online forum two months later. The company revealed the incident publicly on September 18, detailing a chain of events that began with a widely reported supply chain vulnerability.
## The Root Cause: A Compromised Former Employee Account
The breach originated through the account of a former employee whose access to the company’s GitHub organization was not immediately revoked upon departure. The company maintained the account so the individual could complete pending work assignments. However, this decision proved consequential when the former employee’s laptop was infected with malicious software as part of a broader supply chain attack targeting a popular JavaScript package ecosystem.
In May, dozens of malicious versions of packages from a widely used development toolkit were published to a public registry. These compromised packages, once installed on a developer’s machine, executed code designed to exfiltrate sensitive credentials — including GitHub tokens, SSH keys, and cloud service access keys — directly from the infected computer. The vulnerability in the package ecosystem has been assigned the identifier CVE-2026-45321.
Eleven days after the malicious packages were published, the former employee’s GitHub OAuth token was used to duplicate roughly 170 private repositories belonging to the security firm. The company removed the account from its GitHub organization on May 25, three days after the unauthorized copying occurred. The former employee’s other system access had already been deactivated, which is why no unusual activity was detected in the company’s cloud infrastructure.
## What Data Was Exposed
The leaked archive contained several categories of sensitive material. The source code drawn from private repositories included internal web management consoles, data analysis scripts and machine learning models, automation workflows, and the core consensus mechanism that governs how malicious IP addresses are added to the company’s shared blocklist.
Notably, the leak also disclosed configuration thresholds within the consensus algorithm — specifically, the number of detection signals required before an IP address is flagged and blocked. These parameters had not been publicly available prior to the breach. The code itself is described as several months old and has since undergone significant changes.
Beyond the technical source code, the exposed data included the email addresses of 83 active users of the company’s platform, as well as the names, email addresses, and investment details of 51 individuals who had been in discussions with the company as potential investors during 2020. The company noted that the investor records came from an internal system that was never intended to be public-facing.
## Assessing the Damage
The company emphasized that its production infrastructure and databases were never accessed or modified during the incident. No code was altered, and the company maintains that its core threat-detection system remains fully operational. The open-source detection engine, which powers the company’s public-facing security capabilities, was not part of the compromised repositories.
Security researchers also noted that poisoning the company’s shared blocklist would require an extraordinarily coordinated effort — generating tens of malicious detection signals across many independent, trusted nodes operating on separate networks — making such an attack impractical despite the published thresholds.
Only one credential found in the leaked material remained potentially usable: an access token for Amazon Web Services’ Simple Notification Service, limited to publishing messages to a single topic. An unauthorized attempt to use this credential was detected on August 17, but no further exploitation occurred. The company has since rotated all exposed credentials.
## Company Response and Remediation
The company took several steps following the discovery of the leak. All exposed credentials were invalidated on September 16 and 17. The organization has since implemented endpoint protection software on the laptops of all staff members who handle sensitive code or systems — a measure that was not in place at the time of the breach. The company also plans to notify affected users and investors directly and will report the incident to relevant authorities.
The company’s user base, which numbers approximately 150,000, has been advised that no immediate action is required on their part. The exposed user emails are being reviewed by the data science team to understand usage patterns, and affected individuals will be contacted.
## FAQ
**What type of company was affected by this breach?**
The affected organization is a French cybersecurity company that develops an open-source security engine for detecting and blocking attacks on servers. Its platform relies on a distributed network of users who share threat intelligence to build shared blocklists of malicious IP addresses.
**How were the private repositories accessed?**
A former employee’s GitHub account was used to copy the repositories. The employee’s laptop had been compromised by malicious software distributed through tampered npm packages, which stole authentication credentials stored on the machine.
**Was any production system or user data compromised?**
The company states that its production infrastructure, databases, and the open-source security engine were not accessed. However, email addresses of 83 platform users and personal investment details of 51 potential investors were exposed in the leaked data.
**What is the supply chain attack referenced in the disclosure?**
The attack involved the publication of 84 malicious versions of 42 npm packages from a popular JavaScript development toolkit. Installing these compromised packages executed code that stole credentials such as GitHub tokens and SSH keys from developers’ machines.
**Can the company’s blocklist be manipulated as a result of this breach?**
The company believes the blocklist cannot be practically poisoned. An attacker would need to generate a massive number of detection signals across many independent, geographically distributed trusted nodes, which would be extremely costly and difficult to achieve.
**What steps has the company taken since discovering the breach?**
The company rotated all exposed credentials, implemented endpoint protection software on developer machines, removed the former employee’s remaining access, and plans to notify affected users and investors while reporting the incident to authorities.
**Were other companies affected by the same supply chain attack?**
Yes. The same malicious npm packages also compromised systems at other organizations, including a major artificial intelligence company that reported unauthorized access to a limited set of its internal code repositories.
## Conclusion
This incident highlights the cascading risks that supply chain vulnerabilities can introduce into an organization’s security posture. Even after an employee departs, maintaining access credentials — even for legitimate transitional purposes — can create a window of opportunity for attackers who have compromised the departing individual’s devices through indirect means. The case also underscores the importance of promptly revoking all access for former employees and implementing endpoint protection across development environments. While the company has stated that its core systems and databases remain secure, the exposure of internal source code, user emails, and investor information represents a significant operational and reputational challenge that will require careful management going forward. Organizations everywhere can draw from this incident the importance of layered access controls, regular credential audits, and rapid response protocols when personnel changes occur.
Thank you for reading
