On 16 September 2026, CrowdSec publicly confirmed the compromise of around 170 of its private GitHub repositories. The origin: a backdoored TanStack npm package published on 11 May 2026 (CVE-2026-45321), which had extracted a GitHub OAuth token linked to the account of a former employee whose access rights had never been revoked. The source code of the SaaS, connectors and cloud routines was copied. No customer data was exposed. For organisations that use CrowdSec's tools, or more broadly any hosted security tool, the incident raises direct questions about your third-party management programme and your NIS2 obligations.
The incident timeline
On 11 May 2026, an attacker published 84 malicious versions of 42 TanStack packages on the npm registry (source: CrowdSec blog, 16 September 2026). These backdoored packages were designed to extract authentication tokens from the development environments where they were installed. CrowdSec used TanStack in its organisation and was affected through this vector.
On 22 May 2026, an attacker used the GitHub OAuth token thus obtained to clone around 300 repositories from CrowdSec's GitHub organisation, including 170 private repositories. This token was associated with the account of a former employee whose access had not been disabled after their departure.
Public disclosure only took place on 16 September 2026. Nearly four months passed between the initial compromise and official confirmation. The private repositories concerned contain the source code of the SaaS console, AWS routines and proprietary connectors.
Three distinct failures in a single incident
The incident did not result from a single flaw but from three cumulative failures. The first: an npm dependency used without software composition analysis (SCA) that would have detected the compromised versions within 24 to 48 hours of their publication. The second: an OAuth account on GitHub belonging to a former employee that remained active, exactly the kind of orphaned non-human identity that NIS2 programmes must eliminate. The third: a detection delay of several months, incompatible with NIS2 incident notification requirements (24 hours for the early warning, 72 hours for the full notification to the competent authority).
Each of these three points corresponds to a specific category of NIS2 requirements: management of software dependencies (Article 21, paragraph 2, point (d)), management of the access lifecycle (Article 21, paragraph 2, point (i)) and incident detection and response capabilities (Article 21, paragraph 2, point (b)).
Why this concerns you even if you do not use CrowdSec
The first reaction is to check whether CrowdSec appears in your software inventory. This is necessary but insufficient. The incident illustrates a structural risk: your security tools are themselves third-party suppliers that depend on other third-party suppliers.
If you use an open source or SaaS security tool, that tool has its own chain of npm, pip or Maven dependencies. If one of your security tools has been compromised, you may be exposed to future vulnerabilities introduced into the source code before patches are deployed, with no way of knowing this if you do not have a contractual monitoring process.
NIS2 Article 21, paragraph 2, point (d), requires security measures for the supply chain, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. The cybersecurity tools you deploy are service providers within the meaning of this provision. They must appear in your third-party map with the same level of rigour as your data processors.
The blind spots in your TPRM programme
Most third-party risk management (TPRM) programmes categorise their suppliers by type of data processing or by business criticality. Security tools often end up in a separate category, treated differently on the grounds that they are security tools themselves. This is an implicit trust bias that the TanStack-CrowdSec incident illustrates concretely.
The seven classic pitfalls when starting a third-party map include precisely this category of under-assessed tools, as detailed in the article on third-party mapping in 2026. A security tool deployed as an agent on your endpoints has a level of access to your systems that justifies, at a minimum, a maturity assessment equivalent to that of a critical subcontractor.
Two concrete questions to include in your assessments of security tool suppliers:
First question: do you have an inventory of third-party software dependencies (SCA) covering your npm, pip and Maven packages, with an analysis frequency of at least once a week? A supplier that cannot answer this question is not managing this risk.
Second question: what is your documented process for revoking GitHub, AWS and continuous integration access when an employee leaves? Within what timeframe is it applied? The unrevoked access of a former employee was the amplification vector in this incident. CVE-2026-45321 was the initial entry point.
What contractual notification must cover
If the source code of your security supplier is exposed, you need to know. Within what timeframe does your contract require it to notify you? If this clause is absent, you will learn of the incident from specialist media, as many CrowdSec users did.
NIS2 requires each covered entity to manage the risks linked to its suppliers. If your security supplier is itself an important or essential NIS2 entity, it has its own notification obligations to ANSSI (France's national cybersecurity agency). If it is not, your only recourse is contractual. It must therefore be explicit.
Three clauses to verify in your contracts with security tool suppliers: incident notification within less than 72 hours of becoming aware, disclosure of the extent of the exposure and of the data or code potentially compromised, and a right to audit or access the post-incident investigation report.
What this changes in your action plan
The TanStack-CrowdSec incident is not exceptional. It is representative of a class of attacks documented for several years, applied to an actor that had not sufficiently protected its own processes. What is new is that it affects a security vendor that many organisations implicitly assumed had a security posture above the average.
For your TPRM programme, the practical adjustment is limited but precise: include your security tool suppliers in your high-risk third-party category, apply your standard assessment questionnaire to them including SCA, access revocation and contractual notification, and check that their presence in your software inventory is up to date. If some of these tools are deployed as agents or sensors on your systems, the level of access justifies an annual reassessment, not only at contract renewal.