Security1 publisherNot yet confirmed elsewhere3 min readPublished Updated
Reading OIDC tokens out of runner memory: ChainDrop and the poisoned build
Unit 42 says a worm hidden in more than 400 npm packages read GitHub Actions runner memory for temporary OIDC tokens. An SBOM generated at the end of the build would not have seen any of it.
The Watch · Security desk
What happened
- Unit 42 reports the past 12 to 18 months changed the scale and speed of supply chain attacks, with developer tools and code the target rather than finished software.
- Its research names the ChainDrop npm worm, which infected more than 400 packages including the widely used keyv and cacheable-request.
- ChainDrop's preinstall script downloaded the legitimate Bun runtime to launch a 727 KB obfuscated payload in the background.
- Unit 42 places ChainDrop alongside the XZ Utils backdoor (CVE-2024-3094), the Axios account hijack and the Shai-Hulud npm worm.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- constraint The artifact most programmes point at, an SBOM produced at the end of a build, cannot answer whether malware ran during that build, so it is no evidence either way about this class of compromise.
- exposure Because install scripts and editor extensions run unsandboxed with the developer's own permissions, the laptop holding cloud tokens is inside the blast radius of any routine dependency update.
- precedent Since the republished packages kept working normally, teams cannot treat user-visible breakage as the alarm; detection has to come from watching the pipeline, not the bug tracker.
- decision Rolling back package versions and rotating CI credentials no longer closes the incident, which forces a call on whether developer machines get reimaged.
Where ChainDrop went looking for secrets is the detail worth keeping. Alongside a broad sweep for credentials sitting on developer disks, a hidden Python script read live process memory on GitHub Actions runners to lift temporary OpenID Connect tokens and secrets [1]. Federated, short-lived credentials are the standard answer to long-lived keys pasted into CI settings. Reading them out of a running job makes the expiry beside the point, because the worm spends them at once: Unit 42 says it used the stolen npm and GitHub tokens to republish further packages [c9a].
The persistence is the other half of the design. According to Unit 42, ChainDrop wrote cross-linked hooks into developer tooling, including VS Code and Claude Code, and ran its command and control dynamically through Ethereum blockchain transactions [4]. Two things follow from that pairing. There is no domain to seize or sinkhole, and the surviving foothold sits on a laptop rather than in a registry or a runner [13]. An incident closed when the bad versions are unpublished has been closed in the wrong place.
The scale argument underneath this is arithmetic rather than atmosphere. Unit 42 puts open source at 80 to 90 percent of modern codebases and says the surface now includes developer laptops, CI/CD and cloud infrastructure [16]. It also contrasts a project of ten years ago depending on a few dozen external libraries with a simple application today pulling thousands of indirect dependencies [17]. Read at the low end of both figures, that is roughly a 55-fold increase in third-party code arriving per build [19]. Every one of those arrivals can carry a preinstall hook that fires silently the moment someone runs npm install, and ChainDrop's fired at three targets: build server memory, local editor config such as tasks.json, and rogue repositories used to spread further [5].
The reason install-time code works so well is a missing boundary rather than a clever exploit. A browser confines a website to a sandbox; setup scripts and editor extensions have no such walls and inherit the developer's own permissions, free to read files and run commands [7]. That permission grant is handed out constantly, across npm, pip, cargo, go and maven installs, by people also running somewhere between 10 and 30 IDE extensions [18]. Unit 42's summary is that attackers are aiming at CI/CD pipelines and developer environments to hijack software before it reaches production [15], and the ChainDrop mechanics make that concrete.
One caveat on the whole picture: this is a single vendor's research, and the package counts, the payload size and the memory-reading technique are Unit 42's own findings [11]. Nobody else in the reporting has confirmed them.
What to watch
- Whether npm or other registries move to restrict or disable install-time scripts by default, which is the single hook ChainDrop depended on.
- Whether GitHub hardens Actions runners against in-process reads of short-lived OIDC tokens, or treats memory access on the runner as in-scope for the platform.
- Whether researchers outside Unit 42 publish their own package lists and payload analysis for ChainDrop, since the 400-plus figure is currently single-sourced.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence55
- Adoption62
- Hype gap+18
- Incentives80
- Confidence52
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
In ChainDrop's theft stage, a hidden Python script directly read live process memory from GitHub Actions runners to steal temporary OpenID Connect (OIDC) tokens and secrets, alongside a broad sweep for local developer credentials.
- [2]
ChainDrop used stolen npm and GitHub tokens to self-propagate, silently infecting and republishing additional packages.
- [3]
ChainDrop left the legitimate functionality of the packages it republished perfectly intact so that developers do not notice.
- [4]
ChainDrop secured long-term persistence by establishing cross-linked hooks directly inside developer tools including VS Code and Claude Code, and managed its command-and-control infrastructure dynamically through Ethereum blockchain transactions.
- [5]
The malware triggers silently as soon as someone runs npm install, by misusing npm preinstall hooks, and then hits three targets: searching build server memory for unencrypted credentials and platform access tokens, modifying local developer tool configs such as VS Code's tasks.json to retain access after the build, and using stolen tokens to create rogue code repositories for propagation.
- [6]
Unit 42 says generating an SBOM at the end of a build is good for compliance but an inventory created at the finish line will not catch malware that was executed during the build process.
- [7]
A browser locks a visited website in a sandbox, but setup scripts and code editor extensions have no such walls: when they run they get the same permissions as the user, giving malware freedom to read files, steal keys and run commands.
- [8]
Unit 42 has observed attackers spending years pretending to be helpful contributors in order to hide backdoors in core software, as in the XZ Utils case (CVE-2024-3094).
- [9]
Unit 42 cites the Axios supply chain attack as a case of attackers hijacking accounts to drop malware into popular libraries.
- [10]
Unit 42 cites the Shai-Hulud npm worm as a case of attackers misusing setup scripts to automatically steal credentials.
- [11]
The ChainDrop npm worm infected over 400 packages, including widely used libraries such as keyv and cacheable-request, using a three-step chain, according to Unit 42 research.
- [12]
ChainDrop's hook stage modified package manifests with a malicious preinstall script that downloaded the legitimate Bun runtime to silently launch a 727 KB obfuscated payload in the background.
- [13]
ChainDrop's surviving footholds sit outside the scope that package unpublishing and CI token rotation cover, because the persistence artifacts are editor and developer-tool configs on endpoints rather than registry entries or runner state.
- [14]
Unit 42 says supply chain threats have compounded over the past decade but the last 12-18 months brought a drastic shift in the scale and velocity of these attacks, with attackers targeting the everyday tools and code developers rely on rather than only hunting bugs in finished software.
ReportedInsufficientSource: Unit 42 (Palo Alto Networks)2 sources— create a free account to open themView cited source - [15]
Unit 42 says attackers are more focused on poisoning the digital factory that builds an application than the application itself, targeting CI/CD pipelines and developer environments to hijack software at the source before it reaches production.
- [16]
Unit 42 states open-source code makes up 80-90% of modern codebases, expanding the attack surface to developer laptops, CI/CD pipelines and cloud infrastructure.
- [17]
Unit 42 says a project ten years ago might have relied on a few dozen external libraries, while today even a simple application pulls in thousands of indirect dependencies.
- [18]
Developers routinely execute installations across many ecosystems, including npm install, pip install, cargo build, go get and mvn install, while juggling 10-30 IDE extensions.
- [19]
Taking the low end of both of Unit 42's figures, third-party code arriving per build has grown roughly 55-fold in a decade.
Sources
1 independent publisher whose own reporting we read for this story.
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Software Supply Chain SecurityFollow
- Developer Endpoint SecurityFollow
- SBOM and Build ProvenanceFollow
- CI/CD Pipeline SecurityFollow
- Secrets and Token TheftFollow
- npm Ecosystem AttacksFollow
Entities
- Unit 42Follow
- Palo Alto NetworksFollow
- ChainDropFollow
- Shai-HuludFollow
- GlasswormFollow
- XZ UtilsFollow
- CVE-2024-3094Follow
- AxiosFollow
- npm registryFollow
- GitHub ActionsFollow
- BunFollow
- Visual Studio CodeFollow
- Claude CodeFollow
- keyvFollow
- cacheable-requestFollow
- TrivyFollow
- OpenID ConnectFollow
- SBOMFollow
- EthereumFollow