CHAINDROP reads OIDC tokens out of GitHub Actions runner memory — and its opensearch-js path would have shipped a backdoored package carrying genuine, valid npm provenance

UPDATE · originally covered CHAINDROP — the Shai-Hulud npm worm returns through the keyv maintainer, backdoors 400+ packages, and resolves its exfiltration endpoint from an Ethereum smart contract (2026-08-06)

Unit 42 published its own analysis of the CHAINDROP wave on 2026-08-06, and two of its findings change what defenders can rely on rather than adding detail to what they already knew.

The first is credential theft that never touches disk. An embedded Python helper hidden inside an encrypted blob in the payload "locates the Runner.Worker process on GitHub Actions runners, opens /proc/<pid>/maps and /proc/<pid>/mem, and searches live process memory for OpenID Connect (OIDC) tokens and runner secrets" (Unit 42, 2026-08-06). Ephemeral OIDC tokens exist to avoid long-lived secrets sitting in a file or a variable; reading them out of the runner's address space while they are live defeats that design, and any secret-scanning control that inspects files or environment variables at rest sees nothing.

The second is a single-target path that is worse than a forgery. The worm checks three environment variables and only proceeds if it finds itself inside GitHub Actions, in a repository whose name contains /opensearch-js, in a workflow whose reference contains release-drafter.yml; anywhere else in that project it exits and steals nothing, staying silent in exactly the runs a maintainer is most likely to be reading (Unit 42, 2026-08-06). In that path it asks the runner for an OIDC token scoped to npm:registry.npmjs.org and trades it at npm's own trusted-publishing exchange for a real publish credential — the repository's legitimate release identity becomes the attacker's. It then downloads the latest tarball, bumps the patch version and adds a single dependency line typosquatting the project's own scope, never touching install scripts at all, so detections built around preinstall hooks would miss it. Finally it requests a second OIDC token for Sigstore, obtains a Fulcio certificate, builds an in-toto SLSA v1 provenance statement over the tarball's SHA-512 hash, signs it and uploads the entry to the public Rekor transparency log (Unit 42, 2026-08-06).

Unit 42 is explicit about what that means: "This is not forged provenance. The attestation says the tarball was built in that repository by that workflow, and that is true." Its guidance follows directly — a package having valid npm provenance does not mean the package is clean, only that the tarball came out of the workflow named in the certificate, and if that workflow is running attacker code then valid provenance is what you should expect to see. "Pivot on the Rekor log index and the workflow identity inside the certificate, not on whether the signature checks out" (Unit 42, 2026-08-06).

Unit 42 states it did not observe this path execute and that it cannot execute anywhere except in that one workflow in that one repository, but that it is fully implemented and reachable from the payload's main entry point (Unit 42, 2026-08-06). The worm also runs a locale gate before any collection, exiting cleanly on a Russian-language host.