The Miasma worm and its PyPI branch, Hades, are spreading across the npm and PyPI ecosystems right now. They do not wait for a build step or a careless npm install. They run when a developer opens a project or imports a package, and they read secrets straight out of process memory. The defenses most teams rely on, EDR, registry gateways, and SCA scanners, were not built to catch this. Dev Machine Guard's new Suspicious Files feature is, detecting the files these worms drop on developer machines with rules StepSecurity maintains and ships to your fleet automatically.
The StepSecurity research team has been at the forefront of this campaign, tracking each wave as it broke and frequently first to report it: the Miasma npm wave on June 3, the attack on Microsoft's Azure organizations that disabled 73 repositories on June 5, and the Hades PyPI campaign on June 8. Three waves in five days, across two ecosystems. This is moving fast, and the question every security team needs answered is which of their developer machines are affected right now.
Why this is urgent
This is not a single incident to clean up. It is an actively spreading, self-replicating campaign that mutates faster than advisories can keep up.
On June 3, 2026, the Miasma worm compromised 57 npm packages across more than 286 malicious versions in a rolling campaign that lasted under two hours. The largest victim was @vapi-ai/server-sdk, with more than 408,000 monthly downloads. Five days later, on June 8, the same threat actor surfaced on PyPI as the Hades Campaign, compromising ensmallen and roughly two dozen related machine-learning and bioinformatics packages. Between the two ecosystems, researchers counted hundreds of malicious artifacts.
These are worms. Once Miasma or Hades lands on a developer machine, it searches for npm and PyPI publishing tokens, then republishes infected versions of every package that token can publish. Each new victim becomes a new spreader. The speed is the point: when the campaign reached Microsoft's Azure GitHub organizations on June 5, it spread across 73 repositories in under two minutes, and the broader campaign has now infected more than 113 repositories across dozens of accounts. That is why the package count climbs by the hour, and why "which of our developers have this right now" is a question you need answered in minutes, not after the next advisory.
How the attack evolved: from install to import
For years, the supply chain threat model centered on installation. Malicious packages ran their code through preinstall and postinstall lifecycle scripts in package.json, so that is where scanners, allowlists, and CI checks learned to look. Miasma and Hades have moved the execution trigger somewhere those tools do not watch.
Miasma's npm variant uses a technique we call "Phantom Gyp": instead of a lifecycle script, it ships a 157-byte binding.gyp file that triggers code execution during npm install through the native build step, bypassing install-script security checks entirely. The same actor then went further, infecting repositories so the payload runs when a folder is simply opened in an IDE or AI coding assistant, no install required at all.
Hades, the PyPI branch, executes on import. The malicious code is an obfuscated one-line hook embedded in a package's __init__.py. The moment a developer imports the package, the hook downloads a standalone Bun runtime and runs a JavaScript payload. A developer does not have to run anything malicious on purpose. Opening a project in VS Code, or importing a dependency they have used for years, is now enough.
This is the shift that matters: the dangerous moment is no longer install time. It is open time and import time. And the artifacts that carry the payload, a binding.gyp, an injected __init__.py, a .vscode/tasks.json, a .claude/setup.mjs, sit quietly in the project tree and never appear in a package manifest or a lockfile diff.
Why current defenses miss this
Most organizations already run several layers of supply chain defense. Against Miasma and Hades, each one has a blind spot.
Registry gateways and cooldown policies sit at install time. They gate which package versions a client is allowed to fetch from the registry, which is valuable, but it is the wrong checkpoint for these worms. A registry gateway does not see a binding.gyp that fires during a native build, an __init__.py hook that runs on import, or a repository file that executes when the folder is opened. By the time the payload runs, the gateway's job is already done.
EDR is built to flag suspicious process behavior and known-bad binaries. Hades was designed specifically to slip past it: the payload reads secrets directly from process memory, without writing them to disk or making an obviously suspicious network connection, and it runs through a legitimate, signed Bun runtime it downloads on the fly. There is no malware binary to fingerprint and no classic disk-write or exfiltration pattern to alert on. The Hades campaign even ships AI prompt-injection content designed to misdirect automated AI triage systems that try to analyze it.
SCA and dependency scanners inventory what is declared in your manifests and lockfiles. The files that carry these payloads are not dependencies you declared. A binding.gyp, an injected import hook, or an editor config file does not show up in package.json or requirements.txt, so a scanner looking at your dependency graph has nothing to flag.
The common thread: these tools watch the package and the install. Miasma and Hades execute from files on the developer's disk, at open and import time, using memory-resident techniques. That gap is exactly what Suspicious Files is built to close.
What Suspicious Files detects
Suspicious Files flags files associated with known supply chain attacks across all of your enrolled developer machines. The detection rules are managed by the StepSecurity research team and continuously updated based on our own research. StepSecurity is one of the first companies to detect major supply chain attacks, and has been officially credited for discovering several of them, including the compromises of axios and TanStack. Coverage today includes the artifacts behind the Miasma and Hades campaigns:
- A malicious binding.gyp that triggers code execution during npm install (the Phantom Gyp technique)
- Editor and AI-tool configuration files that auto-execute when a project is opened or an AI coding session starts
These editor and AI-tool integration points are increasingly attractive to attackers because they execute with the developer's own access and require no package install at all:
Managed detection, nothing to configure
Suspicious Files works out of the box. The detection rules are authored and maintained by StepSecurity, the same research team that has tracked Miasma and Hades from their first waves and is frequently first to report these campaigns. When the actor mutates, as Hades did when it jumped from npm to PyPI and split its loader and payload to evade detection, we update the rules centrally and your fleet is evaluated against them automatically. There are no rules for you to write, tune, or keep current.
When a file is flagged, the dashboard gives you the full detection record:
- The file path and the device it was found on
- The attack campaign the matching rule is associated with
- A confidence level for the detection
- The file's SHA-256, for correlation and threat-intel lookups
- The matched rule and file-path pattern
- When the file was first and most recently seen on the device
- A condition breakdown showing exactly which indicators matched and which were required
The condition breakdown means a detection is never a black box. You can see precisely why a file was flagged, which makes both validation and triage fast during a live incident.
Why this matters
A compromised developer machine is one of the most valuable footholds an attacker can get. Developer machines hold publishing tokens for npm and PyPI, SSH keys into production, GitHub credentials with elevated scopes, and direct access to CI/CD systems. A file that executes on import or on project open runs with all of that access, and in the case of Miasma and Hades, immediately uses any publishing token it finds to spread the worm further.
Traditional MDM tools understand device posture, not developer workflows. EDR understands process behavior, not supply chain tradecraft. Registry gateways understand installs, not imports. The file a worm drops on disk falls between all of them. Suspicious Files is built specifically for that gap, giving security teams visibility into the files attackers actually use to get code running on developer machines.
How to get started
Suspicious Files is part of Dev Machine Guard and runs on the same lightweight agent you already deploy through your existing MDM or EDR tooling, on macOS, Windows, and Linux. There is no new agent to install and no detection content to manage.
If you already run Dev Machine Guard, Suspicious Files is available now in your dashboard under Developer Machines. Open it to see whether any Miasma or Hades artifacts are present across your fleet.
If you are not yet using Dev Machine Guard, see the Installation Script documentation for rollout guidance, or request a demo to see how it fits into your environment.
Miasma and Hades have already moved past the install-time defenses everyone deployed. They are spreading now, on import and on open. Your visibility needs to be where the code actually runs.
.png)
