The ChainDrop npm worm infected "over 400 packages" — including popular libraries like keyv and cacheable-request — by hiding a three-step, highly evasive chain inside routine developer workflows, Unit 42 reports.
ChainDrop npm worm: the three-step chain and long-term persistence
Unit 42 lays out a compact, brutal playbook. The worm begins with a malicious preinstall script that downloads the legitimate Bun runtime and silently launches a 727 KB obfuscated payload. A hidden Python component then reads live process memory from GitHub Actions runners to steal temporary OpenID Connect (OIDC) tokens and secrets while sweeping local developer credentials. Finally, ChainDrop uses the harvested npm and GitHub tokens to republish and propagate — all while leaving library functionality intact so developers do not notice.
To secure persistence, the malware establishes cross-linked hooks inside developer tooling such as VS Code and Claude Code, and orchestrates command-and-control activity via Ethereum blockchain transactions. The infection is triggered quietly the moment someone runs npm install by misusing npm's preinstall lifecycle hooks.
Developer endpoints: no sandbox, full privileges
Unit 42 emphasizes a structural weakness: setup scripts and code-editor extensions run with the same privileges as the developer and lack the sandboxing web browsers provide. That absence of isolation lets malicious scripts "read your files, steal keys and run commands on your machine" immediately after execution.
Attackers capitalize on this by targeting registries and marketplaces, a trend underscored by the GlassWorm campaign. Beyond silent dependency pulls, compromised IDE extensions that update automatically or changes to editor configuration files (for example, VS Code's tasks.json) give attackers continued access even after a build completes.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleCI/CD pipelines, Trivy, and the need for a pipeline bill of materials (PBOM)
Build pipelines assemble code using many external helpers — scanners, plugins and scripts — often replete with temporary passwords and cloud access keys. Unit 42 points to the compromise of Trivy as an illustration of how pipeline security tools themselves become attractive targets.
For defenders, this means traditional application scanning is not enough. Unit 42 recommends creating a pipeline bill of materials (PBOM): an inventory of every tool running inside the build system. Combined with other controls — restricting CI/CD egress, using ephemeral CI/CD servers and pinning dependencies to exact commit SHAs — a PBOM helps close avenues that malicious setup scripts and worms exploit.
Containers, OpenSSL zero-days (early 2026), and why SBOMs at build-end fall short
Unit 42 stresses that open-source and third-party packages touch every phase of the software development lifecycle (SDLC). Because "open-source code makes up 80-90% of modern codebases," modern applications are assembled from layers of indirect dependencies — often thousands — not written from scratch.
An SBOM generated at the end of a build helps for compliance but can miss malware executed during the build. More critically, container images embed operating-system tools and system libraries such as OpenSSL. The wave of OpenSSL zero-day vulnerabilities disclosed in early 2026 demonstrates that critical flaws deep in a container's OS layer can leave cloud workloads exposed even when application-layer scans report clean.
Unit 42 therefore recommends producing container SBOMs that enumerate both application code and the underlying system components, and coupling these inventories with continuous visibility across developer endpoints, pipelines and runtime workloads.
What this means for technologists, procurement leaders, and developers
- Technologists and security teams: Shift from reactive scans to strict execution control across the build path, enforce short-lived OIDC authentication, require signed commits and signed artifacts, and adopt end-to-end cryptographic provenance to break the trust chains autonomous malware exploits.
- Procurement and enterprise security leaders: Demand PBOMs and container SBOMs — not just a final SBOM — and account for tools inside the pipeline (including scanners such as Trivy) when evaluating third-party risk.
- Developers and tool operators: Harden local environments by disabling lifecycle install scripts (for example, using --ignore-scripts), enforce package cooldown periods, minimize IDE extension exposure, pin dependencies to exact SHAs, and treat registries and marketplaces as high-risk supply-chain vectors.
Unit 42's reporting draws a clear line: attackers are no longer merely hunting bugs in finished applications — they are poisoning the digital factory that builds software. The prescription is practical but demanding: continuous telemetry correlation across endpoints, CI/CD pipelines and cloud runtimes; inventorying every tool that touches a build; and replacing long-lived credentials with ephemeral, cryptographic proofs of provenance. Absent those changes, the same tactics that let ChainDrop and other campaigns hide in plain sight will keep turning developer workflows into self-replicating launchpads.
