Hades Campaign:
A PyPI Worm Hunting AI and Bioinformatics Developers

Updated October 23, 2026: we corrected our detection timings, the block date and the package count against our own records. Earlier versions of this post said our wave correlator grouped the wave and our scorer made block decisions as it happened, and that we caught it days before the first public write-ups. In fact, our first alert came 30 minutes after the first malicious publish, and a public post about the wave followed five minutes later. The correlator grouped the packages on June 9, after the fact, and the first point at which our proxy would block an install was June 10. The campaign covered 38 projects and 68 versions. We alerted on 37 projects and 63 versions, and missed one. We also corrected the api[.]anthropic[.]com/v1/api indicator: it is a path that does not exist on Anthropic's real API host, not an attacker server. We removed a line saying we send a sandbox trace to a model, because our June 5 alerts came from a scanner finding on the .pth file and no sandbox trace was involved.

What happened

A threat actor that researchers track as Miasma published a fresh wave of malicious packages to PyPI in early June 2026. The newest branch of the operation, named Hades after the underworld theme woven through its infrastructure, poisoned 38 PyPI projects across 68 versions. It is part of the broader Mini Shai-Hulud lineage, a family of self-propagating supply-chain worms that steal developer and CI secrets and use them to publish the next generation of infected packages.

What makes Hades worth a close read is the delivery mechanism. Instead of a classic setup.py install hook, the operators shipped a Python path-configuration file, a .pth file, alongside an obfuscated JavaScript payload named _index.js. Any line in a .pth file that begins with import is executed by the Python interpreter every single time the environment starts. That turns a quiet one-line file into reliable code execution that fires on import rather than on install, and it survives in the site-packages directory long after the package looks installed and idle.

The campaign was aimed with intent. Two clusters stand out: bioinformatics tooling used for graph learning, patient phenotyping, and phenopacket workflows, and a set of packages dressed up as Model Context Protocol and AI developer tools. The names were chosen to look at home in the import lists of research labs and AI engineering teams, two communities that move fast and pull niche packages without much friction.

How CyberXYZ flagged the wave about 30 minutes in

Our PyPI firehose ingested the malicious releases as they were published, from June 5 to June 8, 2026. The first malicious release, bramin 0.0.2, went up at 23:15 UTC on June 5. Our scanner had seen earlier, clean releases of a few of these projects in the two weeks before the wave, but nothing in them pointed to the attack. The scanner's first finding came at 23:45 UTC, and the first HIGH alert went out in the CyberXYZ app at 23:46 UTC, 30 minutes after that first publish. The remaining versions of the June 5 wave were alerted at 00:02 UTC on June 6. That was hours before the first public advisory (an OSV record published at 06:13 UTC on June 6) and more than a day before the first vendor write-ups (Socket on June 7, StepSecurity on June 8). It was an alert, not a block, and we do not claim to have been first: a public post about the wave appeared on Bluesky at 23:51 UTC, five minutes after our alert.

Across the whole campaign we alerted on 37 of the 38 projects and 63 of the 68 versions. We missed ensmallen 0.8.101: it was over our scanner's 20 MB size limit at the time, so the scanner skipped it.

Three detection layers were involved, but only one of them acted on June 5. The tarball scanner flagged the Python startup hook under the pth_executable_import signal, which is what triggered the June 5 alerts. The other two layers came later, after the public reports. The wave correlator first ran on June 9 and grouped the releases into waves after the fact. On June 10 at 04:16 UTC, the cross-signal scorer promoted 24 versions in 16 packages to the block list. That is the first point at which the CyberXYZ proxy would have blocked an install.

The wave correlator does something per-package scanners cannot. It fingerprints the actual install-hook payload, not the package name or the install command, and groups packages that ship the same malicious code within a tight publishing window. That is the difference between a triage queue full of noise and a single line that reads: a coordinated multi-package campaign is publishing right now. For Hades, that grouping came after the fact. The correlator first ran on June 9, three days after the first publish, and grouped the Hades releases into two waves by their shared startup hooks.

Timeline of events

• Late May 2026 Earlier Miasma activity seeds the lineage, including npm build-hook worms and IDE and AI-assistant backdoors. Clean releases of a few PyPI projects that the wave later hits pass through the CyberXYZ scanner. None of them is malicious.
• June 5 to 6, 2026 The Hades PyPI wave publishes, starting at 23:15 UTC on June 5. CyberXYZ ingests the malicious wheels, the tarball scanner flags pth_executable_import, and the first in-app HIGH alert goes out at 23:46 UTC. A public post about the wave appears on Bluesky at 23:51 UTC, and OSV publishes the first advisory records at 06:13 UTC on June 6.
• June 7 to 8, 2026 Public analysis of the Hades branch is published. PyPI begins quarantining the affected releases. Total tracked scope reaches several hundred artifacts across npm and PyPI.
• June 9 to 10, 2026 The CyberXYZ wave correlator runs for the first time on June 9 and groups the affected releases into waves after the fact. On June 10 at 04:16 UTC, the scorer promotes 24 versions in 16 packages to the block list, the first point at which the CyberXYZ proxy would block an install. Until then, CyberXYZ alerted on these packages but did not block them.

The attack chain in detail

The execution flow is compact and resilient, built so a single import triggers the whole chain and so it only runs once per host.

1. Startup hook fires on import. The poisoned wheel ships a *-setup.pth file. Its single executable line checks for a sentinel at /tmp/.bun_ran. If the sentinel is absent, deobfuscated Python runs.
2. Bun is fetched on demand. The hook scans sys.path for the bundled _index.js, downloads the Bun JavaScript runtime from the official Bun GitHub releases if it is not already present, and writes the sentinel so the host is not infected twice.
3. The JavaScript stealer runs. The hook executes bun run _index.js. The bundle decrypts its sixteen payloads at runtime and selects an operating-system-specific module.
4. Memory and secrets are scraped. On Linux the stealer walks process memory through /proc, on macOS it calls Mach kernel VM APIs through ctypes without needing root, and on Windows it compiles C# on the fly through PowerShell to read process memory. The high-value target is the CI runner worker process, where it lifts plaintext environment variables and the workflow GITHUB_TOKEN.
5. Exfiltration hides inside GitHub. Harvested secrets are gzip-compressed, encrypted with a fresh AES-256-GCM key, and the key itself is wrapped with the attacker's RSA public key. The bundle is pushed to a newly created public repository under the victim's own GitHub account. The payload also contains an HTTPS sender aimed at api[.]anthropic[.]com/v1/api. That is Anthropic's real API host, not an attacker server, and /v1/api is not a live route on it, so this channel cannot deliver data to the attacker. Socket assesses it as camouflage: traffic to a common AI-vendor host blends into network logs, while GitHub remains the confirmed exfiltration channel.

Hades does not stop at theft. It establishes long-running persistence through user-level service files on Linux and Launch Agents on macOS, drops workspace backdoors into editor and AI-assistant configuration files (for example .cursorrules, .windsurfrules, .github/copilot-instructions.md, and .claude/settings.json) so the payload re-arms inside developer tooling, and injects a GitHub Actions workflow disguised under a benign name to dump repository secrets through the standard artifact upload path. The operators also built a deterrent into the design, wiring destructive behavior to trigger if the stolen token is revoked, which pressures victims to leave the access live.

Two more details show how deliberate this campaign is. First, the loader is not the only delivery path: some samples ship native compiled extensions (.abi3.so files) that execute at import time, so blocking .pth files alone does not close the door. Second, the malware actively hunts for defensive tooling on the host, checking for runtime-security agents and CI hardening tools and their endpoints, and it probes the Docker socket at /var/run/docker.sock for container escape and lateral movement. This is a worm that expects to land on a defended CI runner and tries to work around the defenses it finds.

Indicators of compromise

The following indicators are drawn from published analysis of the Hades branch. File hashes are per-artifact, so treat the names and behaviors as the durable signal and the hashes as confirmation for the specific wheels listed.

Affected PyPI projects

The 38 affected projects are: bramin, cmd2func, coolbox, dynamo-release, executor-engine, executor-http, funcdesc, magique, magique-ai, mrbios, napari-ufish, nucbox, okite, pantheon-agents, pantheon-toolsets, spateo-release, synago, ufish, uprobe, ensmallen, embiggen, gpsea, pyphetools, ppkt2synergy, phenopacket-store-toolkit, nhmpy, mflux-streamlit, rlask, tlask, rsquests, dreamgen, mem8, orchestr8-platform, ray-mcp-server, langchain-core-mcp, instructor-mcp, openai-mcp, and tiktoken-mcp. Confirm exact compromised versions against the official PyPI advisories before remediation.

What was compromised

The stealer casts a wide net across developer and CI secrets: GitHub personal access tokens and the workflow GITHUB_TOKEN, npm, PyPI, RubyGems, and JFrog registry credentials, cloud provider keys, Kubernetes service-account material, SSH private keys, Docker configuration, shell histories, and the contents of .env files and AI developer-tool configurations. Because the worm uses stolen registry credentials to publish the next round of poisoned packages, every successful theft is also fuel for the campaign's spread.

Supply-chain risk analysis

Hades is a clean example of why publish-time behavior matters more than package reputation. None of these projects were typosquats of famous libraries in the traditional sense. They were real-looking research and AI tools whose only tell was the malicious code they suddenly started shipping. The relevant techniques map cleanly to the MITRE ATT&CK framework.

Recommended actions

Immediate. Remove any affected package version from your environments and registries. On any host that imported one, rotate GitHub tokens, registry tokens, cloud keys, and SSH keys, and revoke the workflow tokens for affected repositories. Review and remove any unexpected public repositories, GitHub Actions workflows, persistence services, and editor or AI-assistant config backdoors described above. Assume secrets reachable from the host are exposed.

Short term. Pin dependencies and require review for version bumps on the packages your research and AI teams pull. Treat install-time and import-time code execution as a first-class risk in review, not a footnote. Constrain CI runner permissions so a single poisoned import cannot reach every secret in the environment, and prefer short-lived, least-privilege tokens.

Long term. Put a publish-time behavioral gate in front of your ecosystem. Reputation and version age do not catch a trusted project that suddenly ships a startup hook. Correlation across packages does. A worm that pushes the same payload into thirty projects should read as one loud event, not thirty quiet ones.