Between early June and July 14, 2026, four more supply chain attacks hit npm and PyPI.
The Miasma worm we flagged in our last post did not stop at Red Hat's packages. It kept spreading across npm through June 5, reaching the Vapi server SDK and a string of smaller packages before researchers finished counting. Miasma was not the only worm working in that window. In early June, JFrog uncovered IronWorm, a Rust-built infostealer planted in 36 npm packages that hid behind an eBPF kernel rootkit and spread by using stolen npm credentials to publish trojanized versions of its victims’ packages. That campaign was stopped before it reached widely used packages. Four more attacks followed. A PyPI sibling, two typosquat and credential-theft campaigns, and a CI token theft that backdoored packages with millions of weekly downloads. Different entry points, one objective: land where the credentials live and leave with them.
Attack 1: Hades Brings the Shai-Hulud Worm to PyPI
Shortly after Miasma spread across npm, a matching variant surfaced on PyPI carrying the string "Hades - The End for the Damned."Socket identified it as the PyPI branch of Miasma: the same credential harvesting, the same self-spreading logic, and the same Shai-Hulud habit of exfiltrating stolen data by publishing it to fresh GitHub repositories.
The delivery mechanism was new. Instead of an install hook, Hades shipped a *-setup.pth file that runs automatically at Python startup, fetches the Bun JavaScript runtime, and executes the payload. An initial wave hit roughly 19 packages. A second wave on June 8 pushed the count to at least 29, targeting bioinformatics, graph machine learning, and Model Context Protocol (MCP) libraries. Socket also caught the worm mutating mid-campaign, splitting the loader and payload across sys.path to slip past scanners. Counting both ecosystems, SecurityWeek put the Miasma and Hades total north of 100 packages and 471 malicious artifacts.
Attack 2: Fake Payment SDKs Harvest CI Secrets on npm and PyPI
On July 7, Socket's scanners flagged a coordinated cluster of roughly 17 malicious packages across npm and PyPI, all dressed up as SDKs for well-known payment providers including PaySafe, Skrill, and Neteller. Names like paysafe-checkout, paysafe-node, and neteller were built to be grabbed by a developer moving fast.
The facade was clever. Call payments.create and the package returns { success: true } immediately, so nothing looks broken, while a delayed background routine sweeps environment variables matching KEY, SECRET, TOKEN, PASS, AUTH, or API and ships them to a C2 host behind an ngrok tunnel. The filter explicitly targets AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, and NPM_TOKEN, the exact secrets sitting in a CI runner's environment. The malware even bailed out early when it detected sandbox hostnames or fewer than two CPU cores, and it ran the same playbook in both JavaScript and Python. Detection came fast, within about six minutes of publication, but the design assumed it would.
Attack 3: A Stolen npm Token Poisons Jscrambler
On July 11, an attacker used stolen publishing credentials to push five malicious versions of jscrambler, plus poisoned releases of its webpack, gulp, grunt, and metro plugins, to npm. Per the Socket and StepSecurity analyses, each version carried a native binary compiled for Linux, Windows, and macOS.
The first versions ran the binary from a preinstall hook. Then the attacker changed tactics: later versions dropped the install hook and instead executed on import or when the CLI ran, which meant npm install --ignore-scripts no longer offered any protection. The payload went hunting well beyond the usual cloud keys, reaching for cryptocurrency wallets and, notably, the credential stores of AI coding assistants like Claude Desktop, Cursor, and Windsurf. JFrog identified the implant as an evolved variant of IronWorm, the Rust infostealer from early June, rebuilt to cover macOS and Windows and to automate its own npm propagation. Jscrambler deprecated the bad versions and shipped a clean 8.22.0 the same day; the official advisory counted 1,479 downloads before removal.
Attack 4: AsyncAPI's Own CI Pipeline Turned Against It
On July 14, an attacker opened 37 pull requests against the AsyncAPI generator repository. Nearly all were noise, proposing a fake charity donation page. Buried in the traffic, one PR exploited a pull_request_target workflow that checked out and ran untrusted pull request code, a "pwn request," to steal the highly privileged asyncapi-bot personal access token.
That workflow was a known risk. A contributor had flagged it 58 days earlier and proposed a fix that was still sitting unmerged when the attacker struck. With the stolen token, the attacker pushed malicious commits to two AsyncAPI repositories under a placeholder git identity and let each repository’s own release workflow do the publishing through npm’s OIDC trusted publisher integration. Four packages went out across five versions: @asyncapi/generator, @asyncapi/generator-helpers, @asyncapi/generator-components, and @asyncapi/specs, with combined weekly downloads above 2.25 million. The malicious versions were live for roughly four hours, between 07:10 and 11:18 UTC, before they were pulled from the registry, and lock files generated in that window can still resolve to the poisoned releases. The payload fires on require() rather than install, pulls a multi-stage remote access trojan from IPFS, persists through a systemd service, and holds open command-and-control channels over HTTP, Nostr, an Ethereum smart contract, and a peer-to-peer mesh. It targets browser passwords, SSH keys, npm and GitHub tokens, cloud credentials, and crypto wallets, and it can fetch Gitleaks and HackBrowserData to help with collection. One caveat from Aikido’s analysis: the automated harvesting routines are broken and exit before gathering anything. The shell access is not, so an operator can still take everything by hand.
The payload also ties this attack back to where this post began: it carries Miasma branding. SafeDep reads it as either a private build by the same operators or a copycat that picked up the name after the worm’s source code leaked on GitHub.
The most concerning piece of this for security teams, and something Chainguard called out directly, was that those backdoored packages carried valid Sigstore and SLSA provenance. The attacker did not forge anything. They compromised the CI identity, so the build system signed the malware honestly. Provenance proved where the package came from. It said nothing about whether the source was trustworthy when it was built.
The Common Thread
A worm hiding in a Python startup file, a typosquatted payment SDK, a stolen publishing token, a hijacked CI identity. Four different entry points, all aimed at the same prize: the credentials sitting in developer environments and build pipelines.
The platforms are beginning to close some of the paths attackers have relied on. On July 8, npm v12 disabled install scripts by default, reducing what GitHub called the ecosystem’s largest code-execution surface. But the Jscrambler and AsyncAPI attacks show how quickly that protection can be routed around. Their payloads executed when the package was imported or required, not when it was installed.
The same problem exists in CI. The pull_request_target weakness behind the AsyncAPI compromise belongs to the same class of workflow flaw exploited in the March 2025 tj-actions/changed-files incident. GitHub has since introduced safer defaults in actions/checkout v7, but those protections only matter once teams adopt them. AsyncAPI’s vulnerable workflow remained in place for 58 days after a contributor proposed a fix.
Even provenance could not distinguish a legitimate release from a malicious one. Because the attacker controlled the CI identity, the compromised pipeline produced valid Sigstore and SLSA attestations for the backdoored packages. The signatures accurately proved where the packages came from. They could not prove that the code entering the build was safe.
That is the limit of ecosystem guardrails. They can close known execution paths, harden workflows, and verify how an artifact was produced. They cannot tell a compromised team which credentials the malicious code reached, whether those credentials are still valid, or what access they provide.
By the time a supply chain attack is discovered, those are the questions that determine the blast radius. Answering them quickly requires visibility that exists before the incident: an inventory of secrets across repositories, CI configuration, environment variables, developer machines, and the identities and systems behind them.
