A July 22, 2026 roundup from GitGuardian, aggregating research from Socket, SecurityWeek, and JFrog, pulled together four separate supply chain campaigns discovered between early June and July 14 — and the throughline across all of them is that the npm supply chain attack problem has stopped being about single poisoned packages. It's now about worms that hop ecosystems on their own. The headline entry is Shai-Hulud, the ongoing family of self-replicating npm worms, which spawned a new variant called Miasma that spread across npm through June 5, 2026, reaching packages including the Vapi server SDK. Its PyPI sibling, dubbed Hades, extended the same campaign into the Python ecosystem. Combined, security firm SecurityWeek tallied the two at more than 100 packages and 471 malicious artifacts. If your team still treats npm and PyPI as separately-managed risk surfaces, this campaign is a good reason to stop.
What made Miasma and Hades different from a typical malicious package
Most supply chain incidents follow a familiar shape: an attacker compromises a maintainer account or slips a typosquatted package into a registry, someone installs it, and the damage is contained to whoever pulled that one dependency. Shai-Hulud has never worked that way, and Miasma is the latest proof. As a worm variant, it doesn't just sit inside a single package waiting to be installed — it's built to propagate, spreading laterally across npm packages rather than staying put in one poisoned dependency. That self-replication is the defining trait that separates a "worm" from a one-off malicious upload, and it's why Miasma's reach through early June extended into legitimate, actively used packages like the Vapi server SDK rather than staying confined to a handful of throwaway typosquats.
Hades is the part of the story that should worry teams who assumed npm and PyPI were insulated from each other's problems. Identified by security firm Socket, Hades is described as the PyPI sibling of Miasma — not a coincidental copycat, but a companion payload built for the same campaign, just adapted to Python's packaging mechanics. Its code even carries the tagline "The End for the Damned," a detail Socket flagged as embedded directly in the malware. Hades ships inside a *-setup.pth file, a legitimate Python mechanism that auto-runs at interpreter startup. Once triggered, it fetches the Bun JavaScript runtime and uses it to execute its payload — a cross-ecosystem pivot that lets a Python-based infection chain load and run JavaScript-based malicious code. That's a level of ecosystem-crossing coordination that most defenders' mental models for supply chain risk simply don't account for.
The scale: from 19 packages to over 100 in a matter of days
Hades didn't arrive all at once. Socket's initial detection found it in roughly 19 packages. A second wave landed on June 8, pushing the confirmed count to at least 29 packages — and that second wave wasn't scattershot. It specifically targeted bioinformatics libraries, graph machine-learning tooling, and Model Context Protocol (MCP) libraries. That's a deliberate selection, not an incidental one, and it's worth sitting with why.
By the time SecurityWeek finished tallying the combined Miasma and npm supply chain attack alongside its Hades counterpart, the total had grown to more than 100 packages and 471 distinct malicious artifacts spread across both npm and PyPI. Artifact counts that outpace package counts by that margin usually indicate repeated builds, variant payloads, or multiple malicious versions published under the same package names as the campaign iterated — evidence of an operation that kept working the problem rather than a single drop-and-done attack.
Why targeting MCP and AI/ML libraries specifically is notable
The second Hades wave's focus on graph machine-learning and Model Context Protocol libraries deserves more attention than a footnote. MCP has rapidly become the connective tissue between AI agents and the external tools, data sources, and services they act on — which means an MCP library isn't just another dependency, it's frequently the component that mediates what an AI system is allowed to touch. A compromised MCP package sitting inside an agentic pipeline has a very different blast radius than a compromised utility library sitting inside a web app: it can potentially observe or influence what an AI system reads, writes, or executes on a developer's or organization's behalf.
Bioinformatics and graph ML libraries carry their own version of this risk. These are research and production pipelines that routinely run with elevated access to institutional compute, sensitive datasets, or credentialed cloud environments, often maintained by teams with less mature security tooling than a typical corporate engineering org. An attacker choosing to specifically target this cluster of libraries — AI infrastructure, scientific computing, and graph tooling — during a second, more targeted wave suggests the campaign's operators understood exactly which dependency categories offer the most leverage right now, at a moment when AI tooling's dependence on PyPI packages has never been deeper. Any organization building or embedding MCP servers, agent frameworks, or ML pipelines should read that targeting choice as a direct signal, not a general-purpose warning.
The separate payment-SDK credential harvesting campaign
Layered on top of the worm activity, Socket separately flagged a distinct campaign on July 7, 2026: roughly 17 malicious npm and PyPI packages typosquatting real payment-provider SDKs, with names like "paysafe-checkout," "paysafe-node," and "neteller" impersonating PaySafe, Skrill, and Neteller. This one isn't a worm — it's a more classic, and in some ways more insidious, credential-harvesting play. Calls made to the fake package's API return a convincing "success" response, so a developer integrating the SDK sees exactly what they'd expect from a working payment integration. Meanwhile, a background routine quietly exfiltrates environment secrets — AWS keys, GitHub tokens, npm tokens — to a command-and-control host over an ngrok tunnel.
The "fake success response" detail is what makes this campaign genuinely dangerous rather than merely annoying. A broken or obviously malicious package tends to get noticed and ripped out quickly. A package that returns exactly the response a developer expects can sit in a codebase for a long time, quietly leaking credentials on every invocation, precisely because nothing about the visible behavior signals that anything is wrong.
Why npm's own hardening didn't stop this
It's worth being direct about the timing here, because it undercuts an easy assumption. On July 8, 2026, npm v12 shipped with install scripts disabled by default — a change made specifically to close off the attack surface where malicious code executes automatically the moment a package is installed, before a developer has even looked at what they pulled in. That's a real, meaningful hardening step, and it closes a genuinely common attack path.
But the Miasma and Hades worm campaign, along with the payment-SDK credential harvester, largely execute on import or require rather than at install time. Hades' *-setup.pth mechanism runs at Python startup, not at pip install. The payment-SDK payloads trigger when the fake API is actually called in application code. Neither of those moments is touched by disabling npm install scripts. This is the uncomfortable pattern behind a lot of supply chain hardening: platform-level fixes tend to close the specific door that was most recently exploited, while attackers who are paying attention simply route around it to the next trigger point. Install-time protections are necessary, but this campaign is a clear demonstration that they are not sufficient on their own.
There's also a related lineage worth flagging. IronWorm, a Rust-built infostealer using an eBPF kernel rootkit, was first found hidden inside 36 npm packages in early June 2026. Security firm JFrog identifies it as a related or evolved lineage tied to some of these campaigns — a reminder that the tooling behind these attacks is getting more sophisticated in parallel with the distribution mechanics, not just more widespread. eBPF-based rootkits operate at the kernel level, which puts them well outside what most application-layer scanning or dependency auditing tools are built to catch.
What engineering and platform teams should actually do
None of this is reason to panic, but it is reason to treat "we updated npm" or "we scan for known-malicious packages" as partial answers rather than complete ones. A few concrete, non-exotic steps make a real difference against exactly this kind of campaign:
- Pin dependency versions and audit before upgrading. Floating version ranges are how a worm-based campaign reaches you automatically; a pinned lockfile at least forces a deliberate step before a compromised version lands in your build.
- Run software composition analysis (SCA) tooling continuously, not just at CI time. Miasma and Hades were both caught by dedicated security research firms, not by generic linting — off-the-shelf SCA products that track known-malicious packages and typosquat patterns are worth the investment.
- Treat secrets scanning as mandatory, not optional. The payment-SDK campaign existed specifically to exfiltrate AWS keys, GitHub tokens, and npm tokens from environment variables; scanning for exposed secrets in code and CI configuration closes off the actual payoff attackers are after.
- Isolate CI credentials from developer and production environments. A worm or credential harvester that lands in a CI pipeline shouldn't have a straight line to production secrets or cloud infrastructure access.
- Scrutinize MCP, AI/agent, and ML dependencies with extra care. Given the specific targeting seen in the second Hades wave, treat these categories as higher-risk dependencies deserving more review, not less, even though they're newer and less scrutinized by traditional tooling.
- Watch for eBPF and kernel-level behavior anomalies. IronWorm's rootkit approach operates below where most dependency scanners look; runtime security monitoring that flags unusual kernel-level activity is a meaningful complement to package-level scanning.
- Don't assume install-script restrictions cover you. npm v12's default-disabled install scripts are a good baseline, but this campaign specifically shows payloads triggering on import and require — audit for that behavior separately.
The pattern across Miasma, Hades, and the payment-SDK campaign is the same lesson supply chain security keeps relearning: attackers adapt to whatever specific door just got closed, and self-replicating worms mean a single successful compromise no longer stays contained to one package. Registries, security firms, and platform maintainers are getting faster at catching these campaigns — Socket and JFrog both identified this activity within weeks — but detection after the fact is not a substitute for dependency hygiene that assumes some fraction of what you pull in will eventually be malicious. That assumption, uncomfortable as it is, is what actually holds up when the next worm variant shows up wearing a different name.