By NHI Mgmt Group Editorial TeamBased on Corgea: “Hades PyPI follow-on hit MCP packages and Python typosquats” (June 9, 2026)

TL;DR: The Hades PyPI campaign is shifting from niche scientific packages into MCP helpers, agent-adjacent libraries, and typo-squatted developer tools that commonly sit on workstations and CI runners with GitHub, cloud, SSH, registry, and AI-tool credentials, according to Corgea’s follow-on reporting. That pivot turns package installation into a broader credential-exposure problem, and trust in wheels, startup hooks, and AI-assisted triage now becomes part of the attack surface.


At a glance

What this is: Corgea shows the Hades PyPI campaign moving into MCP and AI developer tooling, where poisoned wheels can reach high-trust workstations and CI runners.

Why it matters: That matters because the exposure is no longer limited to niche Python users, but now includes the credentials and automation paths that identity and security teams must govern across developer environments.


Context

Hades is now a software supply-chain problem with an identity consequence. When malicious Python packages run on developer workstations, notebooks, or CI runners, the practical risk is not only code execution but access to GitHub, cloud, SSH, registry, Docker, Vault, Kubernetes, and AI-tool credentials that those environments routinely hold.

The article’s key shift is the move from specialised research packages into MCP and AI integration tooling, plus typo-squatted packages that blend into everyday developer workflows. That widens the blast radius and makes package trust, runtime trust, and credential governance part of the same control problem.


Key questions


Technical breakdown

How malicious Python wheels execute before the package is imported

A Python wheel can execute code at interpreter startup through a .pth file, which means the payload does not depend on an explicit import of the package itself. When a line in that file begins with import, Python treats it as executable code during startup, before normal application logic runs. In the Hades follow-on, that bootstrap step can locate a payload, download Bun, and hand off execution to a JavaScript stage. The security issue is the trust gap between what teams think they installed and what the wheel runs automatically. Artifact review that stops at package names or source trees misses the startup hook entirely.

Practical implication: Treat wheel startup hooks as execution paths and inspect .pth files during package review.

Why split staging breaks simple wheel scanning

The langchain-core-mcp branch described in the article separates the loader from the payload. The .pth file can search across sys.path and adjacent directories for _index.js rather than shipping the loader and payload together in one obvious archive. That means defenders cannot rely on a single-package heuristic such as looking for both a startup hook and a script in the same wheel. This is a staging pattern, not just obfuscation. It exploits how Python environments are assembled from many small packages, cached wheels, and layered paths, which makes package-to-package dependency review materially harder than file-level malware scanning.

Practical implication: Scan the full environment graph, not just individual wheels, when looking for staged payloads.

How native extensions and cross-runtime loaders hide the real trigger

The native-extension path uses a compiled *.abi3.so module as the loader. Once Python imports that extension, dlopen() loads code that can locate the payload and invoke Bun to run _index.js. That matters because the visible package may look relatively ordinary while the execution trigger sits inside binary extension code. It also changes the review model for AppSec and platform teams: source-only inspection is insufficient when the published wheel contains native code and a second runtime. The result is a cross-runtime attack chain where Python, Bun, and the host process tree all become relevant to detection and containment.

Practical implication: Include compiled extensions and child-process telemetry in package vetting and runtime monitoring.


Threat narrative

Attacker objective: The attacker aims to harvest high-value developer and CI credentials from trusted Python environments and use them for follow-on access and supply-chain abuse.

  1. Entry begins when a developer workstation, notebook, or CI runner installs an affected PyPI wheel such as an MCP helper or typo-squatted Python package.
  2. Credential access follows when the startup hook, split loader, or native extension launches Bun and scrapes GitHub, cloud, SSH, registry, Docker, Vault, Kubernetes, or AI-tool material from the host or process memory.
  3. Impact occurs when the stolen credentials are reused for package publication, workflow manipulation, repository access, or other downstream abuse of the developer trust boundary.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Hades has become a developer-identity exposure problem, not just a package-malware problem. The campaign’s value is in the credentials it can reach from trusted Python execution contexts, especially on workstations and CI runners that sit close to publishing, cloud, and AI operations. That means software supply-chain controls and identity governance now intersect at package install time, not after compromise. Practitioners should treat high-trust developer environments as credential-rich identity zones.

Startup trust is the new weak point in Python package review. The article shows how .pth hooks, split staging, and compiled extensions let malicious wheels execute before normal review workflows notice anything unusual. This is a named control gap in the environment boundary: teams often review package contents as files, but the real security unit is the runtime path. Practitioners should govern interpreter startup, not only dependency names.

AI-assisted triage can become an attacker-controlled analysis surface. The inclusion of prompt-injection content inside package payloads shows that defenders are now being targeted through their own review pipelines. When analysts or tools ingest raw file text, they need to treat package content as untrusted data, not instruction-bearing context. That creates a governance issue for teams using LLMs in malware review and dependency screening. Practitioners should separate analysis automation from execution trust.

Cross-runtime payloads are now a supply-chain pattern worth naming: Python-to-Bun handoff. This is more than a single loader trick. It is a design that deliberately hops runtimes to evade shallow inspection and to exploit assumptions that Python packages only matter inside Python. The control implication is clear: defenders need telemetry and policy that follow the execution chain across runtimes. Practitioners should monitor child-process behavior and package-provenance drift together.

OWASP-NHI matters here because the payload is harvesting machine and developer credentials, not personal accounts. The compromised hosts are valuable precisely because they hold non-human identities such as GitHub tokens, cloud keys, registry credentials, and Vault material. That makes NHI ownership, rotation, and revocation part of supply-chain response, not a separate hygiene exercise. Practitioners should tie package compromise to NHI lifecycle control.

From our research library:

What this signals

Developer workstations are now part of the identity attack surface. When PyPI packages can execute at startup and scrape cloud, registry, and AI-tool secrets from a trusted host, the relevant control boundary is no longer the repository alone. The programme implication is to treat package ingestion, interpreter startup, and non-human identity governance as one workflow, not separate teams.

Python-to-Bun handoff should be treated as a named runtime-bridging pattern. The point is not the specific language combination but the adversary’s habit of shifting execution across runtimes to defeat file-level review. Teams should watch for child-process telemetry that crosses language boundaries and align that detection with NHI secret exposure paths.

According to the State of Secrets Sprawl 2026, 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption. That figure underscores why MCP-adjacent package compromise matters: the credentials stored around agentic tooling are already sprawling, and malicious packages are now positioned to harvest them at the host layer.


For practitioners

  • Inspect Python startup paths for execution hooks Review installed wheels, site-packages, and virtual environments for .pth files, unexpected import lines, and other startup-time code execution paths. Treat any package that can execute before application import as a control event, not a benign dependency.
  • Search developer estates for the named Hades packages Scan requirements files, lockfiles, caches, notebooks, and CI images for the listed package names and versions, then isolate any host that installed them before trusting cleanup.
  • Rotate machine and developer secrets from exposed hosts Assume GitHub, cloud, SSH, registry, Docker, Kubernetes, Vault, and AI-tool credentials on the affected workstation or runner are compromised and revoke or reissue them from a clean control point.
  • Monitor cross-runtime child-process activity Alert on Python processes spawning Bun, downloading bun-v1.3.14 artifacts, or executing _index.js from a package context, because that pattern indicates the malicious payload has already crossed the interpreter boundary.
  • Block AI-assisted review from inheriting trust Keep LLM-based package triage, malware summary, and code-review tools on a strict untrusted-input model so prompt text inside a package cannot influence verdicts or suppress alerts.

Key takeaways

  • The Hades follow-on shows that PyPI compromise is now a developer-identity problem because malicious wheels can reach the credentials sitting on workstations and CI runners.
  • The campaign’s use of startup hooks, split loaders, and native extensions demonstrates that shallow package review is no longer enough to understand what a wheel will execute.
  • The most effective containment step is to isolate affected hosts and revoke exposed non-human and developer credentials before attempting in-place cleanup.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-02 — Secret LeakageThe campaign steals credentials from developer hosts and CI runners after package installation.
NHI-04 — Insecure AuthenticationStolen tokens, keys, and registry credentials turn package compromise into identity abuse.
NHI-07 — Long-Lived SecretsThe attack depends on finding credentials that remain useful after installation-time compromise.
Recommendation — Scan package install paths and runtime caches for exposed secrets and revoke anything the host could have reached. Harden machine authentication so exposed tokens are short-lived, scoped, and revocable on compromise. Reduce long-lived secrets in developer and CI environments and replace them with shorter-lived credentials.
MITRE ATT&CKTA0006;TA0010 — Credential Access; ExfiltrationThe campaign uses package execution to harvest secrets and move them off host.
Recommendation — Map package-induced secret theft to credential-access and exfiltration detections across workstations and runners.
CIS Controls v8CIS-5 — Account ManagementCompromised developer credentials create account abuse across publishing and cloud systems.
Recommendation — Apply account-management controls to revoke and reissue credentials touched by the malicious package install.

Key terms

  • Python Startup Hook: A Python startup hook is code that runs automatically when the interpreter begins, before an application explicitly imports the package. In security incidents, this matters because a malicious hook can execute on any Python launch, widening exposure beyond direct package usage and making host-level scoping more important than lockfile review alone.
  • Split Loader Staging: Split loader staging is an attack pattern where the execution stub and the payload are stored separately, often across different files or paths. This frustrates simple scanners because the malicious behavior is assembled at runtime rather than packaged in one obvious artifact.
  • Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
  • Cross-Runtime Payload: A cross-runtime payload starts in one language or environment and then downloads or invokes components from another runtime to continue execution. This expands the attacker’s reach and weakens assumptions about which tooling stack needs monitoring, especially in build and developer environments.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management in the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps security and identity practitioners connect credential lifecycle control to real-world exposure in developer and automation environments.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org