By NHI Mgmt Group Editorial TeamPublished 2026-06-08Domain: Breaches & IncidentsSource: Orca Security

TL;DR: A coordinated PyPI supply chain attack has compromised 26 packages and 37 malicious wheel files, used Python startup hooks to run cross-runtime malware, and harvested cloud tokens, Kubernetes secrets, GitHub credentials, and AI assistant data across 14 systems, according to Orca Security. The lesson is that package trust, startup execution, and secret exposure must be governed as one identity problem, not separate controls.


At a glance

What this is: A coordinated PyPI supply chain attack abused Python startup behaviour to execute malware, harvest secrets, and spread across developer and cloud environments.

Why it matters: It matters because package trust, workload identity, and secret handling now intersect across NHI, autonomous tooling, and human developer workflows, so compromise can propagate faster than ordinary patching and review cycles.

By the numbers:

  • A coordinated supply chain attack targeting PyPI has compromised 26 packages (37 malicious wheel files) across bioinformatics, graph ML, deep-learning, and developer tooling ecosystems.
  • The payload targets secrets across 14 systems, including AWS, GCP, Azure, Kubernetes, GitHub, PyPI, npm, RubyGems, SSH, Docker, .env files, shell histories, and AI assistant configurations.

👉 Read Orca Security's analysis of the Hades PyPI supply chain campaign


Context

PyPI supply chain compromise is a trust problem, not just a malware problem. When a package release can trigger code at interpreter startup, the attacker no longer needs the target application to import anything explicitly before execution begins.

For identity teams, the issue is broader than developer hygiene. Package ecosystems, CI runners, cloud tokens, and publishing credentials form a single exposure path, which means one compromised dependency can become a credential theft event across multiple environments.

This campaign is atypical only in its breadth and persistence tricks. The underlying pattern, startup-code abuse plus secret harvesting, fits the same failure mode that repeatedly turns software distribution into identity compromise.


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 stolen publishing credentials make supply chain attacks worse?

A: Publishing credentials turn a one-time compromise into a propagation event. Once an attacker can upload new package releases, stolen access becomes the mechanism for seeding additional malicious versions and extending dwell time. Teams should treat publishing authority as a high-value identity asset with tight lifecycle control, not as a convenience token.

Q: How can security teams tell whether secret exposure has become a propagation risk?

A: Look for credential access that can reach package publishing systems, source control, CI, or cloud control planes from the same environment. If one compromised workstation or runner can reuse the same tokens across multiple systems, the blast radius is already expanded. That is the signal to isolate the environment and rotate credentials from a trusted system.

Q: What should teams do after a package supply chain compromise is detected?

A: Contain first, then rotate. Isolate the affected hosts, remove or pin the malicious versions, hunt for persistence artifacts, and rebuild systems where possible before credential rotation. That sequence matters because revoking secrets too early can trigger deterrence logic or simply push the attacker to another compromised environment.


Technical breakdown

How .pth startup hooks turn a package install into execution

Python .pth files can execute import statements automatically when the interpreter initialises, even if the package is never explicitly imported. In this campaign, compromised releases ship a *-setup.pth file that loads an obfuscated hook, which then downloads Bun and runs an _index.js payload. That cross-runtime design is important because it decouples execution from the Python package itself. The malware can therefore operate anywhere Python starts, including virtual environments, CI runners, and developer workstations, without relying on Node.js being installed.

Practical implication: block or inspect package startup hooks and treat interpreter initialisation as an execution boundary.

Why cloud tokens and developer secrets are harvested so broadly

Once active, the payload scrapes memory and local files to collect high-value secrets across Linux, macOS, and Windows. It targets cloud provider tokens, Kubernetes secrets, GitHub PATs and Actions tokens, publishing credentials, SSH keys, Docker configs, and AI assistant data. The point is not just exfiltration. It is credential reuse and propagation, because stolen publishing access can be used to seed additional malicious package versions. That is why package compromise quickly becomes identity compromise across build, deploy, and source control systems.

Practical implication: assume any exposed secret in a build or workstation context can become a propagation path, not just a stolen credential.

How persistence and anti-analysis increase dwell time

The campaign adds a persistence daemon, destructive deterrence if tokens are revoked, and prompt-injection text intended to mislead LLM-based analyzers. It also sends decoy traffic to AI services and encrypts exfiltrated data before publishing it to attacker-controlled repositories. Those techniques raise the operational cost of response because defenders face both technical persistence and analytical noise. The effect is to extend dwell time long enough for stolen credentials to be reused before containment is complete.

Practical implication: pair credential revocation with filesystem, repository, and behavioural hunts so persistence is not left in place.


Threat narrative

Attacker objective: The attacker wants reusable cloud and publishing credentials that let malicious code spread through trusted package channels and unlock broader environment access.

  1. Entry occurs when a poisoned PyPI package installs a malicious .pth file that runs at interpreter startup without requiring an explicit import.
  2. Credential access follows as the payload scrapes memory, shell history, local configs, and cloud, GitHub, and registry tokens from developer and CI environments.
  3. Impact arrives when stolen publishing credentials and GitHub tokens are used to propagate malicious packages, exfiltrate data, and sustain attacker access.

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 trust is now an identity control, not a software distribution preference. The campaign shows that installation-time code execution can convert a benign dependency into a credential collection platform before any application logic runs. That means package governance, publishing rights, and runtime trust are part of the same control plane. Practitioners should treat dependency intake as identity exposure management, not only as vulnerability triage.

Startup-time execution creates an identity blast radius that conventional scanning misses. The relevant failure is not just malicious code in a package, but the fact that interpreter startup is allowed to execute unreviewed instructions. Once the runtime starts, cloud tokens, GitHub credentials, and registry secrets become reachable in the same session. This is why build and developer environments need tighter privilege boundaries than the packages they consume.

Standing publishing authority is the propagation primitive in this campaign. Stolen GitHub and registry credentials are not only exfiltration targets, they are the mechanism that turns one compromised package into many. The control gap is lifecycle persistence of release access, especially where tokens outlive the human or pipeline context that issued them. Practitioners should review who can still publish after trust has already broken.

AI-assisted detection now has an adversarial identity problem of its own. The payload’s prompt injection and decoy traffic show that attackers are already trying to manipulate security tooling that uses language models or AI-assisted classification. That makes the security stack itself a target for identity deception, not just a consumer of threat data. Security teams need to assume adversaries will attempt to shape machine interpretation as part of the attack path.

Ephemeral secret exposure is a governance failure even when credentials are later rotated. This campaign demonstrates how quickly exposed credentials can become operationally useful before response completes. The relevant assumption is that secret exposure is slow enough for manual response to catch up, and that assumption no longer holds across package ecosystems, CI, and developer endpoints. Practitioners should rethink where review and rotation actually happen in the incident sequence.

From our research:

  • The attack sends decoy traffic to Anthropic AI servers to confuse network-level analysis, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
  • Our research also shows that the average estimated time to remediate a leaked secret is 27 days, which is long enough for stolen credentials to be reused in a live campaign.
  • For a broader view of how secret exposure turns into identity compromise, see the 52 NHI breaches Report.

What this signals

Secret exposure is now a cross-domain governance issue. In environments where package install time can trigger execution, the boundary between software supply chain security and identity governance disappears. Teams should link developer workstation control, CI hardening, and NHI credential lifecycle management into one response path.

A practical concept emerges here: startup-time identity exposure. When unreviewed package startup code can read credentials before any application import, the right question is not whether a secret was rotated eventually, but whether it was ever reachable from a trusted execution boundary. For identity programmes, that means reducing the places where credentials can be harvested at interpreter start and validating them against the OWASP Non-Human Identity Top 10.

The broader signal is that attackers are already adapting to AI-assisted detection by manipulating what the security stack sees. That makes package telemetry, secret monitoring, and behavioural analysis part of the same control surface, especially where developer tooling and cloud credentials overlap.


For practitioners

  • Remove or pin away from affected package versions immediately Identify installations of the compromised releases, block them at the repository or lockfile level, and rebuild affected developer workstations and CI runners where possible. Use package inventory and runtime reachability to prioritise assets that can execute the startup hook.
  • Rotate all exposed credentials in dependency and build paths Prioritise GitHub tokens, package registry publishing credentials, cloud provider tokens, Kubernetes secrets, SSH keys, and Docker registry credentials. Rotate from a clean system after isolating affected hosts so the attacker cannot use the same environment to re-harvest secrets.
  • Hunt for persistence artifacts across endpoints and launch agents Search for the named service files, lock files, and repository naming patterns tied to this campaign, then validate whether unauthorized commits or workflow modifications occurred. Include developer laptops, ephemeral CI workers, and build caches in the hunt.
  • Treat interpreter startup as an execution policy boundary Inspect package mechanisms that execute at startup, especially .pth-based hooks, and restrict where unreviewed package code can run. Combine this with tighter controls over secret access in build and runtime contexts so startup-time code cannot reach broad credential sets.

Key takeaways

  • The Hades campaign turns package trust into a credential-harvesting problem, because malicious startup hooks can execute before a package is explicitly imported.
  • The scale matters: 26 compromised packages, 37 malicious wheel files, and 14 categories of secrets show how quickly one dependency chain can expand into identity exposure.
  • The decisive control is faster containment around startup-time execution and secret reachability, not just ordinary package patching.

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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Package compromise exposed secrets and publishing credentials, matching credential lifecycle risk.
NIST CSF 2.0PR.AA-01Identity and credential assurance applies to exposed cloud and registry tokens.
NIST Zero Trust (SP 800-207)PR.AC-4Least privilege matters because startup code reached multiple credential stores.

Restrict and inventory NHI publishing credentials, then rotate and scope them to the minimum release path.


Key terms

  • Python .pth File: A Python .pth file is a startup mechanism that can extend the interpreter path and execute import statements during initialisation. In security terms, it matters because a compromised package can trigger code before any application import occurs, turning package load behaviour into an execution path.
  • Package Supply Chain Compromise: A package supply chain compromise occurs when a trusted software dependency is altered to deliver malicious behaviour to downstream users. The compromise often reaches beyond the package itself, because build systems, developer workstations, and automation environments inherit the trust of the original package source.
  • Secret Harvesting: Secret harvesting is the collection of credentials, tokens, keys, and configuration data from memory or local files after compromise. In practice, it is the bridge between code execution and identity abuse, because stolen secrets often unlock cloud, source control, and publishing systems.
  • Identity Blast Radius: Identity blast radius is the amount of access that can be reached once one identity is compromised. For package and workload environments, it describes how far stolen tokens, publishing rights, and cloud credentials can travel before containment, which is often broader than teams expect.

Deepen your knowledge

Package startup abuse and secret exposure are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment mixes developer tooling, CI, and cloud credentials, it is directly relevant to your governance work.

This post draws on content published by Orca Security: Hades campaign supply chain attack on PyPI packages. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-08.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org