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.
NHIMG editorial — based on content published by Corgea covering the Hades PyPI follow-on: Hades PyPI widens into MCP toolchains and AI developer workstations
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
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
👉 Read Corgea's analysis of the Hades PyPI follow-on targeting MCP and AI tooling →
Hades PyPI campaign: what MCP and AI teams need to know?
Explore further
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.
A few things that frame the scale:
- 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.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
A question worth separating out:
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.
👉 Read our full editorial: Hades PyPI widens into MCP toolchains and AI developer workstations