Hades PyPI widens into MCP toolchains and AI developer workstations

At a glance

What this is: This follow-on analysis shows Hades moving from specialist Python packages into MCP and AI developer tooling, with malicious wheels designed to trigger credential theft during normal Python startup.

Why it matters: It matters because developer workstations, notebooks, and CI runners often hold high-value secrets, so package supply-chain compromise can become an identity and access incident very quickly.

👉 Read Corgea's analysis of the Hades PyPI follow-on targeting MCP and AI tooling

Context

Python package compromise is no longer only a software integrity problem. When malicious wheels land in developer tooling, the real risk is that package installation becomes a path to credential exposure, cloud access abuse, and downstream supply-chain compromise. In environments that mix Python runtimes with MCP helpers and AI-integrated workflows, the boundary between code execution and identity compromise is thin.

The Corgea article shows a practical shift in attacker targeting: from niche scientific environments toward broadly privileged developer workstations, AI-agent sandboxes, notebooks, and CI runners. That is a typical progression for supply-chain attacks because the easiest place to steal GitHub tokens, cloud keys, SSH material, or registry credentials is often the place developers trust most: their own tooling.

Hades supply-chain drift: the campaign is widening from specialised research packages into mainstream AI and MCP developer environments, which increases both reach and blast radius.

Key questions

Q: What breaks when a malicious Python package uses startup hooks instead of a normal import path?

A: The assumption that code only executes when an application imports it breaks down. A .pth file can run at interpreter startup, so installation alone may be enough to trigger payload staging, credential discovery, or child-process execution. That means package review must include startup semantics, not just visible source files or explicit imports.

Q: What breaks when supply-chain poisoning reaches developer workstations and CI runners?

A: The main failure is assuming a compromised package only affects one project. In practice, developer hosts and CI runners often hold cloud tokens, source access, and signing credentials, so a poisoned dependency can become a broader trust-breach across repositories and deployment paths. Once that happens, traditional package scanning is no longer enough on its own.

Q: How can security teams spot a hidden loader and payload split across packages?

A: Look for package-to-package dependency patterns, sibling files, shared cache paths, and runtime searches across sys.path rather than assuming one wheel contains the whole attack. A loader that is harmless in isolation can still stage a payload from another installed package or directory, so detection must correlate artifacts at runtime.

Q: Who is accountable when a compromised package exposes cloud or developer secrets?

A: Accountability sits with the teams that own maintainer credential governance, release controls, CI/CD hardening, and secret rotation. If a compromised dependency touched systems with sensitive credentials, the response must include revocation, reconstruction, and post-incident access review. Software supply chain incidents are identity incidents, not just build failures.

Technical breakdown

How malicious .pth startup hooks execute before the package is imported

A .pth file in site-packages is processed automatically when Python starts. If a line begins with import, Python executes it during interpreter initialisation, before the developer explicitly imports the malicious package. That makes startup itself the execution edge. In the reported Hades wave, the loader can scan sys.path for a payload, stage a Bun runtime, and run JavaScript without relying on a normal application import path. The security consequence is that installation alone may be enough to trigger compromise on a workstation, notebook, or CI runner.

Practical implication: treat suspicious .pth files as executable code, not metadata, and inspect startup hooks during dependency review.

Why split-loader staging defeats simple wheel inspection

The follow-on packages reportedly separate the loader from the payload so that the wheel can look harmless in isolation. One package may contain only a startup hook, while another path or sibling package holds the _index.js stage the loader later discovers. This breaks naive detection rules that look for a .pth file and the payload in the same artifact. The pattern matters because MCP and AI helper ecosystems often install many small, adjacent packages, making cross-package staging easier to hide during casual review.

Practical implication: analyse installed package sets and runtime paths together, not each wheel in isolation.

How native extensions and cross-runtime loaders expand the attack surface

A compiled *.abi3.so extension can act as the trigger even when the Python source looks benign. Once Python loads the binary extension through dlopen(), the code can locate a JavaScript payload and invoke Bun to execute it. That is an important supply-chain pattern because source review, sdist review, or Python-only static checks may miss the actual execution path embedded in the published wheel. The result is a cross-runtime compromise chain where Python, Bun, and the host filesystem all participate in the attack.

Practical implication: include binary wheels, extension modules, and child-process telemetry in package security controls.

Threat narrative

Attacker objective: The attacker wants to harvest high-value development and cloud credentials from trusted build and AI-integrated environments, then reuse them for repository abuse, publishing, or lateral access.

1. Entry occurs when a developer workstation, notebook, or CI runner installs one of the malicious PyPI wheels, often through trusted-looking MCP or AI integration package names.
2. Credential access begins when Python startup executes a .pth hook or native extension that locates the staged payload and launches Bun to run the hidden JavaScript stealer.
3. Escalation follows as the malware searches for GitHub, cloud, SSH, registry, Docker, Vault, Kubernetes, and AI-tool credentials already present in the runtime or accessible from the host.
4. Impact is credential theft and follow-on repository, cloud, or CI compromise from the trusted development environment.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Palo Alto Networks Key Breach — Supply chain breach compromises Palo Alto Networks and exposes customer credentials and information.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Package compromise has become an identity event, not just an AppSec event. When a malicious wheel lands on a developer workstation or CI runner, the attacker is targeting the credentials already trusted by that environment. GitHub tokens, cloud keys, registry secrets, and AI-tool credentials are identity assets, so the governance problem sits directly at the intersection of supply-chain security and NHI control. Practitioners should stop treating package review as a purely code-centric activity.

Developer tooling is now a high-value credential concentration point. The move into MCP helpers and AI-adjacent packages matters because those environments often blend human identity, service credentials, and machine access in one runtime. That creates a broader attack surface than traditional application code alone. The practical conclusion is that access scope, package provenance, and secret exposure need to be governed together, not as separate controls.

Hidden execution paths are the new package-trust failure mode. The most useful named concept here is runtime-artifact ambiguity: the published wheel, the startup hook, the binary extension, and the staged payload do not look dangerous when inspected separately. That ambiguity weakens review processes that assume a single artifact tells the whole story. Teams need runtime-aware control decisions because the malicious behaviour is revealed only after installation and interpreter startup.

AI-assisted triage can become an attack surface when untrusted package text is treated as instructions. The reported prompt-injection block inside the payload is a reminder that analysts and automation tools need strict separation between data and instructions. This is where AI governance intersects with package security in a concrete way. If the triage pipeline can be manipulated by embedded text, the attacker is now shaping detection as well as execution.

The campaign shows how supply-chain threats will increasingly target the environments closest to secrets. Rather than focusing only on production hosts, attackers are going after the places where developers sign in, publish, deploy, and connect AI tooling. That widens the governance burden across IAM, PAM, secret handling, and workstation control. Practitioners should assume developer environments are identity-critical assets, not convenience zones.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• From our research: 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• For deeper context: The 52 NHI breaches Report shows how credential exposure repeatedly turns into follow-on access abuse across environments.

What this signals

Developer environments are becoming identity control points, which means package security, secret governance, and privilege management can no longer be separated. The practical next step is to treat build hosts, notebooks, and AI development sandboxes as NHI-rich environments that deserve the same lifecycle discipline as production systems.

Runtime-artifact ambiguity: teams need to expect malicious behaviour that only emerges after install time, interpreter startup, or cross-runtime handoff. That changes the monitoring model from static file review to runtime correlation across Python, child processes, and secret access events.

For practitioners, the governance signal is clear: if a package can reach a secret, it is part of your identity attack surface. Controls aligned to the 52 NHI breaches Report and external references such as OWASP Agentic AI Top 10 help teams map that exposure more accurately.

For practitioners

• Inspect installed wheels for startup hooks and binary triggers Search site-packages, wheel caches, and virtual environments for .pth files, *.abi3.so modules, and unexpected child-process launches tied to Python startup. Quarantine any environment where installation alone can trigger Bun, curl, or similar runtime execution.
• Reclassify developer secrets as identity assets Inventory GitHub, cloud, SSH, registry, Docker, Vault, Kubernetes, and AI-tool credentials on developer hosts and CI runners, then apply the same lifecycle controls you use for privileged accounts.
• Add cross-package staging checks to dependency review Review installed package groups together so a loader in one wheel cannot hide a payload in a sibling package, adjacent path, or shared cache. This is especially important in MCP and agent-adjacent ecosystems that use many small helpers.
• Harden AI-assisted triage against instruction injection Treat embedded package text, comments, and payload strings as untrusted data when feeding them to LLM-based analysis or summarisation tools. Use extraction and sanitisation steps before any model sees package contents.

Key takeaways

• The Hades follow-on campaign shows supply-chain compromise moving into the same environments that hold developer identity and machine credentials.
• The most important technical change is hidden execution at Python startup, which makes package installation itself a potential compromise event.
• Teams should govern developer hosts, CI runners, and AI tooling as credential-bearing assets, with runtime-aware package review and faster secret rotation.

Key terms

• Runtime-artifact ambiguity: A failure mode where malicious behaviour is hidden across multiple package artifacts, loaders, or runtime stages rather than visible in one file. It matters because reviewers who inspect source, sdists, or single wheels in isolation can miss the real execution path until the code runs.
• Startup hook: An automated command or action that runs when an AI tool starts a session or reaches a specific lifecycle event. Hooks are powerful because they execute without fresh user approval, which makes them dangerous if an attacker can modify the configuration that defines them.
• Developer endpoint as an identity surface: A developer workstation or laptop becomes an identity surface when it stores, uses, or can exfiltrate reusable credentials. In practice, that means local shells, package managers, AI assistants, and browser sessions all participate in access risk, even when no production system is directly targeted.
• Cross-runtime loader: A loader that starts in one runtime, such as Python, but pulls in and executes a payload in another runtime, such as JavaScript under Bun. This complicates static analysis because the visible package language does not fully describe the behaviour that occurs at execution time.

What's in the full analysis

Corgea's full research note covers the operational detail this post intentionally leaves for the source:

• Package-by-package indicators for the named malicious versions and how to validate them in local environments
• Reverse-engineering detail on the .pth, split-loader, and *.abi3.so execution paths
• Concrete scoping steps for virtual environments, wheel caches, and CI runners after exposure
• The exact response guidance for isolating hosts and rebuilding clean images

👉 Corgea's full post covers the package indicators, loader paths, and response steps in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programme that protects development and deployment environments.