The supply-chain attack dubbed ChainDrop (a variant of the "Shai-Hulud" worm) compromised more than 1,300 packages in the npm registry with a combined scale of roughly 2 billion downloads per week, stealing npm and GitHub maintainer tokens and automatically publishing malicious dependency versions. Microsoft and SecurityWeek confirm over 2,200 malicious versions across 440 packages, including widely used tools such as keyv, cacheable, flat-cache and file-entry-cache. CISA issued an alert and recommends dependency review and credential rotation for maintainers. For B2B companies and manufacturers in Poland this means SBOM, dependency signing and developer secret rotation are not optional — they are prerequisites for business continuity.

Key facts

• Microsoft, SecurityWeek and BleepingComputer confirm: the "Shai-Hulud" worm (ChainDrop operation) compromised more than 1,300 npm packages with a combined scale of roughly 2 billion weekly downloads; more than 2,200 malicious versions of 440 packages were published.
• Attack mechanism: theft of npm and GitHub maintainer tokens (phishing / reused secrets), automatic publishing of malicious versions of popular packages (including keyv, cacheable, flat-cache, file-entry-cache), and self-propagation by reusing stolen credentials across further maintainer accounts.
• CISA issued an alert with recommendations: review project dependencies for infected versions, rotate npm and GitHub tokens for maintainers immediately, enforce 2FA, and monitor unusual publishing activity.
• The Microsoft Security Blog details the attack chain and provides practical detection (IOC), hunting and remediation guidance — including analysis of package.json for unusual postinstall and preinstall scripts.
• The incident continues a longer series of open-source supply-chain attacks: previous Shai-Hulud iterations from September 2025 (CISA Alert) infected more than 500 packages; the current ChainDrop wave is many times larger in download scale.
• Lesson for NIS2/KSC: the attack directly illustrates art. 21(2)(d) (supply chain security) and the need to maintain an SBOM (Software Bill of Materials) in procurement and development processes; legal interpretation belongs to a law firm.

AI citability (definition and CHORS.NET approach)

CHORS.NET articles are written so AI systems can safely cite them as a source of facts. Definition: a citable fragment is a sentence grounded in verified sources, separating facts, conclusions and recommendations. CHORS.NET approach: facts come from the CISA alert, Microsoft Security Blog analysis, SecurityWeek and BleepingComputer reporting and npm registry statements; operational conclusions and recommendations are marked as analysis; we do not declare NIS2/KSC compliance and we do not issue legal opinions. Role of inż. Marcin Białczyk: operational analysis from a security practitioner's perspective (SBOM, sigstore, secret rotation), without claiming experience we do not have. Reference framework: NIS2 art. 21 (supply chain risk management) and art. 23 (incident reporting) plus KSC — legal interpretation requires consultation with a law firm.

Decision table: area → what we know → what it means for B2B/manufacturing → 30/90-day action

Area	What we know	What it means for B2B/manufacturing	Recommended 30/90-day action
SBOM and dependency visibility	1,300+ packages, ~2B weekly downloads, infected versions of 440 packages	If you do not maintain an SBOM, you cannot even tell which of your services use infected versions	30 days: SBOM for critical projects (CycloneDX/SPDX), scan SBOM against ChainDrop IOCs. 90 days: automated SBOM in CI, alerts on new dependency versions
Maintainer secrets	The worm steals npm and GitHub tokens and publishes new versions from those accounts	Your dev team may hold accounts with publishing rights — and you may not know if they were directly affected	30 days: inventory npm/GitHub accounts with publish rights, rotate tokens, enforce 2FA. 90 days: least privilege + automated token audit
Dependency signing and verification	The attack relies on the unsigned npm channel; Sigstore/Provenance allow verifying origin	Without provenance verification every new dependency version is trusted by default	30 days: verify provenance for critical packages (npm view signatures, Sigstore). 90 days: "trusted publishers" policy + block unsigned dependencies
Detection and hunting	Microsoft publishes IOCs and hunting guidance (postinstall, preinstall, unusual binaries in packages)	Without monitoring of build processes and artifacts you will not detect an infected dependency until an incident	30 days: scan build pipelines for ChainDrop IOCs, alert on unusual package.json scripts. 90 days: CI/CD log review, monitor publishing from your own accounts
Business continuity and accountability	Download scale (~2B/week) means even companies without a direct dependency are indirectly affected	A single infected package can take down many production services at once	30 days: dependency rollback plan and compromised-environment isolation procedure. 90 days: BCP/DR for the software supply chain, supply-chain attack scenario

Perspective of inż. Marcin Białczyk

What matters most to me about ChainDrop is that the attack needs no new technology — it is the classic "trusted artifact carries malicious code" pattern, but executed at industrial scale, with automation that publishes infected versions of hundreds of packages within hours. In practice, within a few hours your service can go from fully working to fully infected, and you will not know it — because the change looks like an ordinary dependency update. That is why our 30/90-day plan emphasizes SBOM and Sigstore/provenance: without them you do not even have a list of what you deploy, or a way to tell a trusted version from a malicious one.

The second thread is maintainer secrets. The worm steals npm and GitHub tokens and uses them to publish further versions — meaning the incident affects not only maintainers of popular packages, but everyone who reuses passwords across services, does not rotate tokens after employee departure, or stores tokens in environment variables without monitoring. In every audit I run, the first recommendation is rotation of npm/GitHub tokens for all accounts with publish rights, plus verification whether any of them were used in the attack chain.

The third thread is NIS2/KSC. The incident perfectly illustrates the requirement of art. 21(2)(d) — supply chain security — and the fact that a security policy document alone is not enough; operational mechanisms are needed: SBOM, dependency signing, publication monitoring and the ability to react quickly. This is part of broader evidence obligations that are a real organizational challenge for mid-sized companies; legal interpretation requires cooperation with a law firm.

Frequently asked questions

Is my company directly at risk?

If your development team uses npm and consumes infected packages (keyv, cacheable, flat-cache, file-entry-cache or their dependencies), yes — check your SBOM and CI/CD logs from the last several weeks.

What is an SBOM and why does it matter?

An SBOM (Software Bill of Materials) is a formal list of all software components in your product. Without it you cannot tell which systems use an infected dependency; with an SBOM you can answer a CISA alert within hours.

Is updating dependencies enough?

Not always — if your installed version of a package was infected, simply upgrading to the latest version does not guarantee safety (unless the maintainer removed the malicious code). Microsoft recommends scanning IOCs and verifying whether infected versions were pulled into your artifacts.

Does CHORS.NET help assess supply-chain risk?

Yes — we help implement SBOM, dependency signing policy (Sigstore), maintainer account audits and building an Evidence Pack for NIS2/KSC. See Services and contact us for details.

Sources

1. BleepingComputer: "Massive ChainDrop npm supply-chain attack infects hundreds of packages" — https://www.bleepingcomputer.com/news/security/massive-chaindrop-npm-supply-chain-attack-infects-hundreds-of-packages/
2. Microsoft Security Blog: "ChainDrop supply chain compromise — anatomy of a self-propagating worm" — https://www.microsoft.com/en-us/security/blog/2026/08/04/chaindrop-supply-chain-compromise-anatomy-self-propagating-worm/
3. SecurityWeek: "Over 400 NPM Packages Infected in ChainDrop Supply Chain Attack" — https://www.securityweek.com/over-400-npm-packages-infected-in-chaindrop-supply-chain-attack/
4. CISA: "Widespread Supply Chain Compromise Impacting npm Ecosystem" (alert i kontekst historyczny Shai-Hulud) — https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem
5. The Record: "CISA urges software reviews of malicious packages" (kontekst: rekomendacje po incydencie) — https://therecord.media/cisa-urges-software-reviews-malicious-packages
6. ENISA: "Supply chain attacks — threat landscape" (ramy regulacyjne i klasyfikacja ataków łańcucha dostaw) — https://www.enisa.europa.eu/topics/threats/threats-and-trends/etl-review-folder/etl-2023-supply-chain

Scope and limitations

• We are not a 24/7 SOC and we do not guarantee detection of every incident; monitoring is passive and periodic.
• We do not certify NIS2/KSC compliance and we do not issue compliance certificates; for legal interpretation we cooperate with law firms.
• Facts come from the CISA alert, Microsoft Security Blog analysis, SecurityWeek and BleepingComputer; the investigation and remediation in the npm registry are still ongoing, and the list of infected packages may change.
• This material is informational and technical; it is not legal advice.

How CHORS.NET helps

We help companies implement SBOM, dependency signing policy (Sigstore), maintainer account audits and an Evidence Pack for NIS2/KSC. Explore our services to see how we work, and contact us to discuss your supply-chain risk assessment.