
Miasma and Hades Are Spreading Now: Detect Them on Developer Machines with Suspicious Files
StepSecurity details the fast-moving Miasma (npm) and Hades (PyPI) supply-chain worm campaigns, which shifted the execution trigger from install-time lifecycle scripts to open-time and import-time: Miasma uses a "Phantom Gyp" technique via a malicious binding.gyp that fires during native npm builds, while Hades embeds an obfuscated hook in __init__.py that downloads a Bun runtime and reads secrets from process memory on import. The post explains why EDR, registry gateways, and SCA scanners all miss these artifacts (they aren't declared dependencies and don't touch disk in classic ways), then pitches StepSecurity's Dev Machine Guard "Suspicious Files" feature, which scans developer machines for known attack artifacts using centrally maintained detection rules.
What it is
Miasma (npm) and its PyPI branch Hades are a self-replicating supply-chain worm campaign attributed to a single threat actor, active across three waves in five days: the Miasma npm wave (June 3, 2026), the takedown of 73 Microsoft Azure GitHub repos (June 5), and the Hades PyPI wave (June 8). The summary covers the package counts; what it does not carry is the specific artifacts to hunt for and the self-replication mechanism that makes this urgent rather than a one-off cleanup.
How it works
The worm's payload is triggered not at install but at open time and import time. On npm, "Phantom Gyp" uses a 157-byte binding.gyp that fires during the native build step; the actor also infected repositories so the payload runs merely by opening a folder in an IDE or AI coding assistant — no install at all. On PyPI, an obfuscated one-line hook in __init__.py downloads a standalone Bun runtime on import and runs a JS payload that reads secrets from process memory.
The replication loop is the reason the package count climbs hourly: once on a machine, the worm searches for npm and PyPI publishing tokens, then republishes infected versions of every package that token can publish. Each victim becomes a spreader — it hit 73 Azure repos in under two minutes, and the campaign has now reached 113+ repos across dozens of accounts.
flowchart LR
O[Open folder / import pkg] --> P[Payload runs]
P --> M[Read secrets from process memory]
P --> T{Publishing token found?}
T -->|yes| R[Republish infected versions] --> O
T -->|no| E[Exfil only]What to do
The payload files sit in the project tree and never appear in a manifest or lockfile diff, so dependency scanners miss them. Hunt developer disks for these on-disk artifacts:
binding.gyp(npm native-build trigger, ~157 bytes)- injected/obfuscated
__init__.pyimport hooks (PyPI) .vscode/tasks.json.claude/setup.mjs
Treat "which developer machines carry these files right now" as a minutes-scale question. Rotate any npm/PyPI publishing tokens exposed on affected machines, since token theft is how the worm propagates.
Caveats
The page's specific detection ("Suspicious Files") is StepSecurity's own Dev Machine Guard product, so the file-hunt list above is vendor-sourced rather than an independent advisory. The page also warns the campaign is mutating faster than advisories, and that Hades ships AI prompt-injection content designed to misdirect automated AI triage — so automated analysis of samples may be actively deceived. The page text is truncated before the full feature description.
Technologies named here
- npm ecosystem
- Dev Machine Guard
- Suspicious Files
- @vapi-ai/server-sdk
- PyPI ecosystem
- EDR
- Microsoft Azure GitHub organizations
- Registry gateways / cooldown policies
- axios
- SCA and dependency scanners
- tanstack
- npm
- PyPI
- Bun
- VS Code
- node-gyp
- StepSecurity
Techniques named here
- Phantom Gyp
- Import-time execution hook
- In-memory credential theft
- Publishing token theft and worm propagation
- AI prompt-injection for triage evasion
Threat actors named here
Related in Supply Chain


