# 'Hades' Campaign Targets PyPI with Shai-Hulud Variant, Compromising 37 Wheels Across 19 Packages


Threat actors have launched a fresh wave of supply chain attacks against the Python Package Index (PyPI), exploiting a sophisticated self-propagating malware variant to infiltrate developer infrastructure. The "Hades" campaign, detailed by security researchers at Socket, represents a continuation of persistent threats to the open-source ecosystem, demonstrating how attackers are evolving their tactics to maintain footholds in critical software repositories.


## The Threat


The latest campaign compromised 37 malicious PyPI wheels distributed across 19 distinct packages, according to Socket's research team announcement published June 8, 2026. The malware variant, tracked as a descendant of the Shai-Hulud worm, operates as a self-propagating credential stealer designed to:


  • Extract developer credentials and cloud authentication tokens
  • Gain unauthorized access to PyPI and other repository accounts
  • Publish poisoned package versions to downstream developers
  • Establish persistent footholds in the open-source supply chain

    • While PyPI had already quarantined some of the malicious releases by the time Socket published their findings, the research team reported the remaining compromised packages directly to PyPI's security operations team for immediate remediation.


    ## Background and Context


    Shai-Hulud first emerged as a significant threat in September 2025, initially targeting npm (the Node Package Manager) ecosystem before expanding its reach to PyPI. The worm's persistence reflects a troubling trend: attackers have moved beyond one-time package injection attacks toward self-sustaining, self-propagating threats that compromise the accounts of developers who download infected code.


    This represents a fundamental escalation in supply chain attack sophistication. Rather than simply publishing malicious packages and hoping for downloads, Shai-Hulud variants establish persistent access by:


    1. Infecting a developer's local environment

    2. Stealing repository credentials

    3. Using those credentials to publish new poisoned versions

    4. Repeating the cycle with each newly infected developer


    The "Hades" nomenclature appears to be the attacker's naming convention for recent waves of the campaign, while a related variant targeting Red Hat Cloud Services packages was previously identified as Miasma—indicating possible coordination or shared infrastructure among threat actors.


    ## Technical Details: The Attack Chain


    ### Cross-Runtime Design


    The most distinctive feature of the Hades campaign is its cross-runtime approach—a deliberate design choice that sets it apart from traditional malware families that assume specific programming environments will be available.


    Unlike typical Python attacks that rely on the local Python interpreter or npm attacks that assume Node.js is installed, Shai-Hulud variants depend on Bun, a modern JavaScript runtime, as their execution engine. This architectural decision serves multiple tactical purposes:


  • Environment independence: The attack succeeds regardless of the developer's primary toolchain
  • Detection evasion: Security tools optimized for Node.js or Python may miss Bun-based payloads
  • Persistence: Bun execution persists across different development contexts
  • Flexibility: The same malware can target multiple ecosystem communities with minimal modification

    • ### Python .pth Exploitation


    The PyPI-specific variant leverages Python's .pth (path) file mechanism—a legitimate startup behavior that allows developers to extend Python's module search paths. When a Python environment initializes, it automatically executes code in .pth files located in the site-packages directory.


    Attack flow:


    1. Malicious wheel is installed via pip

    2. Installation includes obfuscated .pth file

    3. On next Python invocation, .pth file executes silently

    4. Bun JavaScript runtime is installed or invoked

    5. JavaScript stealer payload executes, harvesting credentials

    6. Stolen tokens grant access to developer accounts and repositories


    This approach exploits Python's convenience feature to bootstrap arbitrary code execution—developers installing the wheel have no visibility into the background credential harvesting.


    ### Obfuscation and Payload Strategy


    Socket researchers identified "heavily obfuscated" JavaScript code within the Bun payloads, indicating the attackers invest significant effort in evading static analysis. The obfuscation likely includes:


  • Variable name mangling
  • Control flow flattening
  • String encoding and decoding layers
  • Dynamic code generation

    • | Attack Component | Purpose | Signature |

    |---|---|---|

    | Wheel package | Distribution vector | PyPI malicious wheels |

    | .pth file | Startup trigger | Python path initialization |

    | Bun runtime | Execution engine | Cross-runtime independence |

    | JavaScript stealer | Credential harvest | Dev token exfiltration |

    | Repository access | Propagation mechanism | Account compromise |


    ## Implications for Organizations


    ### Developer Ecosystem Risk


    This campaign poses cascading risks to any organization consuming Python packages:


  • Supply chain contamination: Developers unknowingly installing Hades-infected wheels bring malware into enterprise CI/CD pipelines
  • Lateral movement: Compromised developer credentials can grant access to internal repositories and private code
  • Cloud infrastructure access: Stolen cloud authentication tokens can enable direct access to AWS, Google Cloud, or Azure resources
  • Multi-layer infection: An infected wheel in one project can propagate across an organization's entire Python ecosystem

    • ### Distinction from Previous Attacks


    Previous supply chain attacks relied on discoverability—attackers published malicious packages and hoped developers would accidentally install them (often through typosquatting or dependency confusion). Shai-Hulud represents a dangerous evolution: it doesn't depend on organic discovery because it creates its own distribution network through compromised developer accounts.


    Even if PyPI removes the initial 37 wheels, the underlying threat persists as long as any developer downloaded them—their compromised credentials continue publishing new variants.


    ## Recommendations


    ### Immediate Actions


    For all Python developers:

  • Audit recent pip installations against the 19 compromised packages identified by Socket
  • Review terminal history for any pip installs from unknown or suspicious sources
  • Rotate credentials immediately if you have installed packages from untrusted sources in the past 6 months
  • Check PyPI account activity for unfamiliar package uploads or authentication events

    • For security teams:

  • Scan dependency manifests (requirements.txt, poetry.lock, pipenv.lock) for references to compromised packages
  • Monitor repository activity for unusual publish events or version changes from developer accounts
  • Implement supply chain SBOMs (Software Bill of Materials) to track exact package versions in production
  • Alert developers to rotate cloud credentials (AWS keys, GCP service accounts, Azure tokens)

    • ### Long-Term Defenses


    | Defense Strategy | Implementation |

    |---|---|

    | Package signing | Require cryptographic signatures for all internal packages |

    | Private mirrors | Host internal PyPI proxies with pre-vetted packages |

    | Dependency pinning | Lock exact versions rather than allowing auto-updates |

    | Sandboxed CI/CD | Isolate build environments to limit credential exposure |

    | Credential scoping | Use temporary, narrowly-scoped tokens for package operations |

    | Behavioral monitoring | Detect unusual repository publish events from developer accounts |


    ### Repository Hygiene


    Organizations should implement two-factor authentication (2FA) on all PyPI and npm accounts, enforce unique, machine-generated API tokens for CI/CD operations, and regularly audit repository collaborators and permissions.


    The fact that Shai-Hulud variants now target multiple ecosystems (npm, PyPI, and potentially others) suggests this is no longer an isolated campaign but rather an established attack pattern that will likely persist and evolve.


    ---


    ## HackWire Analysis


    The Hades campaign illustrates why package managers have become the critical vulnerability in modern software development: they're trusted infrastructure that's simultaneously impossible to fully vet. A developer can install one malicious wheel and expose their entire organization's cloud infrastructure.


    What's particularly insidious here is the self-sustaining mechanism. Previous supply chain attacks required attackers to continuously publish new malicious packages or hope their initial release achieved high enough adoption. Shai-Hulud inverts this: it's designed to *create* compromised accounts that become force multipliers for the malware itself. Once 37 wheels infect developers across 19 packages, those developers' compromised credentials can publish hundreds more packages—and the attacker doesn't need to lift a finger.


    The cross-runtime design (using Bun instead of assuming Python or Node.js) is equally revealing. This suggests mature threat actors who've learned that environment-specific attacks fail against polyglot development teams. By bundling their own execution environment, they guarantee their payload runs regardless of the target's tech stack.


    The real danger isn't the 37 wheels PyPI already quarantined—it's the unknown number of developer accounts now compromised and silently publishing new poisoned packages. Every day this campaign runs undetected by individual developers is another day their credentials publish new variants. Organizations need to treat potential infection here as a critical incident requiring immediate credential rotation across all cloud and repository systems, not just a "pip uninstall" exercise.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Breaches](https://www.hackwire.news/category/breaches) coverage
  • Cross-reference with [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)