Hades campaign shows how PyPI supply chain attacks steal cloud credentials

At a glance

What this is: This is an analysis of the Hades Campaign PyPI supply chain attack, which used Python startup hooks to execute malware and harvest cloud credentials at scale.

Why it matters: It matters because package trust, CI and developer runtime hygiene, and NHI credential governance are no longer separable for teams running Python-based software supply chains.

By the numbers:

• A coordinated supply chain attack targeting PyPI has compromised 26 packages and 37 malicious wheel files.
• The attack targeted 14 systems with credential theft and exfiltration activity.

Context

PyPI supply chain attacks are now an identity governance problem as much as a software integrity problem. When compromised packages can execute at interpreter startup and reach cloud tokens, GitHub credentials, and Kubernetes secrets, the security boundary is no longer the package repository alone.

The Hades Campaign shows why traditional separation between build trust, runtime trust, and secret governance breaks down in Python ecosystems. A package can arrive through normal dependency channels yet still create an execution path that exposes non-human credentials across developer machines and CI environments.

Key questions

Q: What breaks when a compromised Python package can run code at interpreter startup?

A: Package trust breaks down because the code runs before a developer or pipeline explicitly imports anything. That means secret scraping can begin as soon as Python initialises, reaching cloud tokens, GitHub credentials, and local configs in the same session. The practical consequence is that package intake must be governed as execution risk, not just dependency risk.

Q: Why do supply chain attacks on Python packages turn into cloud credential theft so often?

A: Because developer and CI environments usually hold the exact tokens attackers want: cloud provider credentials, GitHub access, registry keys, and Kubernetes secrets. Once malicious package code runs, it can search memory and local files faster than teams can detect it. The risk is amplified when secrets are broadly reachable from build or test workloads.

Q: What are the signs that a package supply chain attack has reached credential theft stage?

A: Look for unusual startup hooks, unexpected outbound downloads, repository creation with attacker-like naming patterns, new persistence services, and unauthorised workflow or commit activity. In this campaign, exfiltration and propagation were tied to those behaviours. Those signals suggest the issue has moved beyond package compromise into identity abuse.

Q: How should teams respond when package-based malware can touch developer and CI secrets?

A: Contain the affected environment first, then revoke the tokens and publishing credentials that were reachable from it. After that, rebuild the systems that executed the malware and inspect repositories for unauthorised changes. The key point is that response must address both code integrity and NHI compromise, not one or the other.

Technical breakdown

How .pth startup hooks turn trusted packages into execution paths

Python .pth files are processed when the interpreter starts, before an application explicitly imports most packages. That means a malicious wheel can place code in a startup hook and gain execution simply because the environment is running Python, not because a developer chose to invoke the package. In this campaign, the hook downloaded Bun and launched an obfuscated payload, which makes the malware runtime-agnostic once startup occurs. The security issue is not only package compromise but the fact that interpreter initialization becomes an execution boundary for attacker-controlled logic.

Practical implication: treat interpreter startup files and package install paths as execution surfaces, not passive metadata.

Why cross-runtime payloads widen package supply chain blast radius

The malware used Python only as the entry point and then shifted execution into a JavaScript payload running on Bun. That cross-runtime pattern matters because defenders often scope monitoring to the language ecosystem they believe is in use. By pulling in a separate runtime, the attacker bypasses assumptions that Node.js would be the only JavaScript execution layer to watch. This is a supply chain design pattern, not a single-language malware event, and it increases the number of telemetry planes security teams must consider.

Practical implication: inventory secondary runtimes and treat them as part of software supply chain threat modelling.

How secret harvesting turns package compromise into credential theft

Once active, the payload searched memory and local files for AWS, GCP, and Azure tokens, Kubernetes secrets, GitHub credentials, SSH keys, and registry configurations. That makes the compromise much more than code tampering, because the attacker is using package execution to reach the identity material that controls cloud access and software publishing. In NHI terms, the package is the delivery vehicle, but the real target is the secret estate. The blast radius expands quickly when developer, CI, and registry credentials are available in the same runtime context.

Practical implication: separate developer and CI secrets from routine package execution paths and limit token reachability.

Threat narrative

Attacker objective: The objective was to steal high-value cloud and publishing credentials, then use them to expand package compromise and sustain access.

1. Entry occurred through compromised PyPI package releases that installed malicious .pth startup hooks.
2. Credential access followed as the payload harvested cloud tokens, GitHub credentials, Kubernetes secrets, and other secret material from memory and local files.
3. Escalation and propagation happened when stolen publishing credentials enabled further package compromise and self-spreading behaviour.
4. Impact included exfiltration of secrets to attacker-controlled repositories and broader exposure across developer and CI environments.

Breaches seen in the wild

• Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.

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

Package trust is no longer separable from identity trust: when a dependency can execute at interpreter startup, the package manager becomes an access path into cloud credentials. That means PyPI compromise is not just a software supply chain event, it is a route to non-human identity theft across developer and CI environments. Practitioners need to treat package admission, runtime execution, and secret exposure as one governance domain.

Interpreter startup is the new privilege boundary: .pth hooks let attacker code run before an application meaningfully begins. That collapses the assumption that package installation and code execution are distinct phases, because the installation artefact itself can trigger credential access. The implication is that runtime trust must be evaluated at startup time, not only at import time or deploy time.

Ephemeral build assumptions fail when publishing credentials remain reachable: supply chain governance often assumes CI runners are disposable, yet the campaign shows that runner-accessible tokens and registry credentials can be harvested and reused elsewhere. The issue is not just that secrets exist, but that they remain reachable inside execution contexts that were never meant to broker identity. Teams should reassess whether their build systems are acting as credential reservoirs.

Software supply chain compromise has become an NHI governance problem: stolen GitHub, cloud, and registry tokens are the true operational asset in attacks like Hades. Once those tokens are exposed, package propagation, repository tampering, and environment access all become identity abuse outcomes rather than isolated malware stages. The practitioner conclusion is clear: NHI inventory, lifecycle, and offboarding must extend into developer tooling and package workflows.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Ephemeral package trust now needs credential reachability controls: a malicious dependency can execute before application code and still reach tokens, keys, and workflow secrets. That means runtime isolation and secret scoping have to be designed together, not treated as separate hardening tasks.

Package compromise becomes identity compromise when tokens are reusable: once a stolen GitHub or cloud token can authenticate elsewhere, the attacker has moved from code execution to portable access. The governance question is whether your NHI estate is still exposed anywhere a build or test process can touch it.

For practitioners

• Audit package startup execution paths Identify any .pth, sitecustomize, or similar startup mechanisms that can run before application code and flag them as execution surfaces. Remove unnecessary startup hooks from build and runtime images.
• Rotate exposed cloud and publishing credentials Prioritise GitHub tokens, PyPI and npm publishing credentials, cloud provider tokens, Kubernetes secrets, SSH keys, and registry credentials that were reachable from affected environments. Do not wait for perfect containment before revocation.
• Hunt for persistence artefacts in developer environments Search for gh-token-monitor, update-monitor, and the lock files and service entries associated with the campaign across developer workstations and CI runners. Rebuild hosts where compromise cannot be confidently excluded.
• Audit repositories for unauthorised changes Review commit history, workflow files, and newly created repositories for names and behaviour that match the attacker patterns described in the campaign. Treat unexpected repository activity as a sign that publishing credentials were abused.

Key takeaways

• The Hades Campaign shows that a PyPI compromise can become a cloud credential theft event as soon as startup code can reach token-bearing environments.
• The attack combined package tampering, cross-runtime execution, and secret harvesting to widen the blast radius beyond Python itself.
• Teams should treat package trust, startup execution, and NHI credential governance as one control problem, not three disconnected ones.

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.
• 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.
• Secret Harvesting: Secret harvesting is the extraction of credentials, tokens, or keys from an execution environment rather than from an authentication flow. It often targets files, memory, environment variables, and local configuration, which makes trusted developer and CI contexts high-value targets.
• Container Supply Chain Attack: A container supply chain attack manipulates the systems that build, package, or distribute container images. Instead of attacking only the runtime, the adversary abuses trusted automation, poisoned source, or compromised registries to spread malicious behavior through normal development workflows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.