Shai-Hulud Hades PyPI Campaign: 19 Packages Trojanized via Wheel Startup Hooks

A PyPI supply-chain campaign in the Shai-Hulud / Mini Shai-Hulud / Miasma lineage compromised 19 Python packages by shipping trojanized wheel artifacts. Researchers observed 37 malicious wheels that add a Python startup hook (*.pth) to trigger code execution, then bootstrap a Bun runtime to run an obfuscated JavaScript credential stealer. The technique can execute without importing the affected package, so routine dependency installs can turn into developer workstation and CI compromise.

This post covers what happened in the Hades PyPI supply chain attack, how the execution chain works, what is at risk, and what defenders should do now.

What Happened in the Shai-Hulud Hades PyPI Wave?

Researchers reported a coordinated compromise affecting 37 malicious wheel artifacts across 19 PyPI packages, largely in the research and scientific Python ecosystem. The publishing pattern looks consistent with a single maintainer account takeover, followed by mass publishing of consecutive patch releases across that maintainer’s package portfolio.

Several established tools were highlighted as higher-risk examples in the affected set, including:

• dynamo-release
• spateo-release
• coolbox
• ufish
• napari-ufish

Why Is This Incident a Developer and CI/CD Compromise Risk?

This is best treated as a secrets theft and pipeline compromise scenario, not a traditional customer data breach. The payload’s goal is to harvest credentials and developer secrets that can enable:

• Lateral movement into source control (especially GitHub)
• Abuse of CI/CD runners and workflow secrets
• Takeover of publishing identities for further supply-chain spread (PyPI, npm, RubyGems, artifact registries)

In practice, one infected developer workstation or build runner can expose tokens that unlock multiple downstream systems.

How Does the Malicious PyPI Wheel Execute Without Importing the Package?

The key technique is a Python startup hook: a *-setup.pth file embedded inside the wheel.

Python’s site module processes .pth files at interpreter startup. If a .pth file contains a line beginning with import, Python can execute it automatically. That means execution can occur simply by:

1. Installing the wheel
2. Starting a Python interpreter afterward

No explicit import compromised_package is required, which increases risk for CI runners and developer machines that routinely create environments and invoke Python as part of builds, tests, notebooks, or tooling.

What Is the Python → Bun → _index.js Execution Chain?

The malicious wheels include two notable artifacts:

• A *-setup.pth startup hook
• An obfuscated JavaScript payload named _index.js

The loader logic observed by researchers attempts to:

1. Create a sentinel file to avoid repeated execution (example behavior referenced: a marker like /.bun_ran in a temp location)
2. Locate the adjacent _index.js
3. Download and install Bun (observed targeting Bun v1.3.13 from GitHub releases in the loader logic)
4. Execute the stealer via bun run _index.js
5. Write the sentinel and exit

Bun usage is a defining fingerprint in this lineage. Rather than relying on a preinstalled Node.js runtime, the malware bootstraps its own JavaScript runtime to run the credential stealer.

Researchers also noted an implementation nuance: in local CPython reproduction, the loader’s path resolution may not reliably locate adjacent _index.js exactly as written, but the wheels remain clearly malicious and are designed to bootstrap and run the JS payload.

What Secrets Does the Payload Target, and How Does It Persist?

The campaign focuses on broad developer secrets harvesting, including:

• GitHub tokens and GitHub Actions secrets
• Publishing and registry tokens such as npm, PyPI, RubyGems, and JFrog
• Cloud credentials across AWS/GCP/Azure, plus Kubernetes and Vault
• SSH keys and Docker credentials
• Files such as .env, .npmrc, .pypirc, and shell histories
• Configuration related to Claude/MCP tooling

For exfiltration and operator workflows, researchers observed GitHub-centric markers and “Hades/underworld” themed naming conventions associated with components and repository descriptions. Reporting also described a secondary exfiltration method via HTTPS that points to a legitimate but invalid Anthropic API endpoint as camouflage.

Persistence mechanisms reported include systemd services on Linux and LaunchAgents on macOS, with additional attention to developer tooling and workflow configurations that can support follow-on access and propagation.

Is There Confirmed Attribution or Known Victim Impact Related to the Hades PyPI Supply Chain Attack?

Researchers tie the wave to the Shai-Hulud / Mini Shai-Hulud / Miasma lineage based on tradecraft, especially the Bun bootstrapping and the obfuscated JavaScript stealer. However, public attribution to a specific actor is not conclusively established beyond that lineage linkage.

Aggregate download volume was described as hundreds of thousands of downloads across the affected packages, but public reporting did not confirm specific victim organizations or verified downstream breaches tied to this 19-package wave. Treat claims of named victims or end-user data exposure as unconfirmed unless primary disclosures appear.

SOCRadar’s Supply Chain Intelligence module gives your organization a 360° view of third-party risk by continuously evaluating vendors across 133 security check items – spanning Attack Surface Management, Cyber Threat Intelligence, and Digital Risk Protection. When a package maintainer account is compromised or a trusted tool in your ecosystem is weaponized, SOCRadar’s Security Trust Scores and real-time vendor monitoring surface the exposure before it reaches your pipeline.

At the same time, SOCRadar’s Dark Web Monitoring keeps watch on the underground channels where harvested developer credentials end up – GitHub tokens, cloud keys, PyPI publishing identities, and CI/CD secrets. When exfiltrated data from a compromised build environment surfaces in threat actor markets or Dark Web forums, SOCRadar alerts your team with the context to rotate and contain before attackers move laterally into your infrastructure.

What Should Defenders Do Now If PyPI Environments Might Be Exposed?

Contain and assess exposure

• Inventory developer machines and CI runners for installation of the affected package versions tied to this wave.
• Treat any host that installed a malicious wheel as potentially exposed, even if the package was never imported.

Rotate credentials

Assume credential compromise and rotate anything reachable from the affected environment, especially:

• GitHub personal access tokens, GitHub App credentials, Actions secrets
• Cloud keys and short-lived role credentials where applicable
• Artifact and publishing tokens (PyPI, npm, RubyGems, JFrog)
• SSH keys and deploy keys
• Kubernetes and Vault tokens

Rebuild from known-good state

Where practical, rebuild developer environments and CI runners or restore from known-good backups after eradication. Given the persistence behaviors reported (systemd, LaunchAgents), cleaning a host is riskier than reimaging.

Hunt using high-signal behaviors

Prioritize detection around these markers:

• Wheels containing executable *-setup.pth hooks and an embedded _index.js
• Unexpected Bun downloads from GitHub releases, especially during Python environment setup
• Process ancestry patterns such as python → bun followed by suspicious outbound traffic
• New or unusual systemd units or LaunchAgents appearing shortly after package installation
• Unexpected GitHub workflow changes, new secrets usage, or anomalous token activity