PyPI Supply Chain Security in 2026: Shai-Hulud Wave 2, the Hades Campaign & How to Protect Your Python StackSécurité Supply Chain PyPI en 2026 : Vague 2 Shai-Hulud, Campagne Hades & Comment Protéger vos Projets Python

PyPI has become the second most dangerous package registry for supply chain attacks in 2026. According to Sonatype's Q2 2026 Open Source Malware Index, PyPI accounted for 48.5% of all non-npm malicious package activity — and the threat actor behind much of that activity is TeamPCP, a financially motivated, cloud-specialist group that has conducted the most sophisticated cascading supply chain campaign in PyPI's history.

This article covers the full arc of that campaign in 2026: the original TeamPCP kill chain (March 2026), the open-sourcing of the Shai-Hulud worm (May 12, 2026) and the explosive Wave 2 that followed, and the Hades campaign (June 8, 2026) which targeted bioinformatics and Model Context Protocol (MCP) developers on PyPI with a novel .pth startup hook delivering a Bun-based credential stealer. Then we cover what you can actually do about it.

Act I: The TeamPCP Kill Chain (March 2026)

To understand the Shai-Hulud waves, you need to understand how TeamPCP operates. Their strategy in March 2026 was a cascading credential chain: compromise the security tools that have privileged access to CI/CD pipelines, steal the credentials those tools can see, and use them to backdoor popular packages.

Act II: The Worm Goes Open Source (May 12, 2026)

The TeamPCP March campaign fed into something far larger: the Mini Shai-Hulud npm+PyPI worm. Starting April 29, 2026, TeamPCP launched a coordinated worm attack targeting the npm and PyPI registries simultaneously — a historic first. Over two weeks, 172 packages across 404 malicious versions were compromised, hitting TanStack, Mistral AI, Guardrails AI, and UiPath among others.

Then, on May 12, 2026 — one day after the massive TanStack compromise — TeamPCP did something unprecedented: they published the full Shai-Hulud worm source code to GitHub as open-source software, with a $1,000 XMR bounty challenge to whoever could run the largest supply chain attack using the code. Within 48 hours, the first clone appeared. Wave 2 had begun.

Act III: The Hades Campaign — PyPI's .pth Persistence Problem (June 8, 2026)

Just when the Shai-Hulud wave seemed to plateau, security researchers at Socket, Endor Labs, and StepSecurity disclosed a new and more technically sophisticated campaign on June 8, 2026: the Hades campaign. Named for its underworld theme, Hades targeted an entirely different victim profile: Python bioinformatics researchers and developers building on Model Context Protocol (MCP).

Six Python packages used in academic genomics, phenotype analysis, and graph machine learning were simultaneously replaced with trojanized versions — including ensmallen, embiggen, pyphetools, gpsea, phenopacket-store-toolkit, and ppkt2synergy. The expanded Socket research found 471 total artifacts (411 npm + 60 PyPI) across 37 PyPI wheels, including MCP-themed packages like langchain-core-mcp, and typosquats like rsquests, tlask, and rlask.

How the .pth Hook Works — Persistence Beyond Import

What makes Hades technically remarkable is its delivery mechanism. Unlike previous supply chain attacks that required the malicious package to be imported, Hades used Python's .pth file mechanism — a feature designed for extending the Python path, but capable of executing arbitrary code on every Python startup.

# Hades delivery mechanism — simplified
# 1. Malicious wheel installs an innocuous-looking file:
#    site-packages/ensmallen-setup.pth

# 2. Python processes ALL .pth files in site-packages at startup
# 3. The .pth file triggers import of the malicious module

# 4. The malicious module downloads Bun JavaScript runtime
#    and runs _index.js — obfuscated credential stealer
#
# Target credentials:
#   AWS_SECRET_ACCESS_KEY, GOOGLE_APPLICATION_CREDENTIALS
#   GITHUB_TOKEN, NPM_TOKEN, PYPI_TOKEN, RUBYGEMS_API_KEY
#   JFROG_ACCESS_TOKEN, Kubernetes service account tokens
#   SSH private keys (~/.ssh/), shell history, .env files
#   Docker config (~/.docker/config.json)
#   AI tool configs: ~/.claude/, ~/.cursor/, ~/.gemini/

The key threat: once a Hades-compromised package is installed in a virtual environment, every Python process in that venv exfiltrates credentials at startup — even processes completely unrelated to the malicious package. This means a bioinformatics researcher running genomics analysis scripts would silently leak their GitHub token and AWS keys on every execution.

The Scale: 2026 PyPI by the Numbers

PyPI Trusted Publishers: The Right Architecture With Real Limits

PyPI's Trusted Publishers system — based on OIDC tokens rather than long-lived API keys — is the right answer to credential theft. Instead of storing a static token in CI/CD secrets, your workflow exchanges a short-lived OIDC token for a 15-minute PyPI upload token. There is no secret to steal, rotate, or accidentally commit.

# .github/workflows/publish.yml — Trusted Publishers pattern
jobs:
  publish:
    permissions:
      id-token: write  # Required for OIDC exchange
    steps:
      - uses: pypa/gh-action-pypi-publish@release/v1
        # No TWINE_PASSWORD or API_TOKEN needed
        # PyPI verifies the OIDC token from GitHub

Over 50,000 PyPI projects now use Trusted Publishers, representing more than 20% of all file uploads. But the TeamPCP campaign revealed important limitations that developers need to understand:

Defence Guide: Protecting Your Python Projects in 2026

Step 1: Audit for Hades .pth Infections Right Now

Check all your virtual environments for suspicious .pth files before doing anything else:

# Find all .pth files in your active venv
find $(python -c "import site; print(site.getsitepackages()[0])") \
     -name "*.pth" | xargs grep -l "import\|exec\|__import__" 2>/dev/null

# List all .pth files for manual review
find $(python -c "import site; print(site.getsitepackages()[0])") \
     -name "*.pth" -exec echo {} \;

# Legitimate .pth files contain only paths, not import statements
# Any .pth file with "import" or "exec" is suspicious

Step 2: Run pip-audit on Every Project

# Install pip-audit
pip install pip-audit

# Audit installed packages (uses OSV database)
pip-audit

# Audit a requirements.txt without installing
pip-audit -r requirements.txt

# Audit a poetry.lock
pip-audit --fix  # auto-fix where possible

# JSON output for CI/CD integration
pip-audit --format=json --output=audit.json

Step 3: Add OSV-Scanner to CI/CD

# GitHub Actions — add to your existing workflow
- name: OSV Scanner
  uses: google/osv-scanner-action@v2
  with:
    scan-args: |-
      --lockfile=requirements.txt
      --lockfile=poetry.lock
      --call-analysis=all

# OSV covers PyPI, matches against osv.dev database
# Updated within hours of new PyPI advisories

Step 4: Hash-Pin Dependencies in requirements.txt

# Generate pinned requirements with hashes
pip-compile --generate-hashes requirements.in > requirements.txt

# Example output (with integrity check on install):
# requests==2.32.3 \
#     --hash=sha256:70761cfe03c773ceb22aa2f671b4757976145175cdfca038c02654d061d6dcc6 \
#     --hash=sha256:...

# Install respects hashes — any tampering fails
pip install --require-hashes -r requirements.txt

Step 5: Enable PyPI Trusted Publishers

• Go to PyPI project settings → Publishing → Add a new pending publisher
• Configure: GitHub owner + repository + workflow file name + environment name
• Use on: push to a protected branch (never on: pull_request alone)
• Add branch protection: require PR review, no direct pushes, no force-push
• Revoke all existing long-lived PyPI API tokens once OIDC is working
• Enable mandatory 2FA on all maintainer PyPI accounts

Step 6: Monitor with Socket for Python

Socket's pypi_socket integration flags packages with install-time execution hooks, obfuscated code, and known malware lineages including Shai-Hulud, Hades, and TeamPCP payloads. For projects with direct PyPI exposure, Socket's package health signals provide a second layer of detection beyond pip-audit's CVE-only scope.

Frequently Asked Questions

PyPI est devenu le deuxième registre de paquets le plus dangereux pour les attaques supply chain en 2026. Selon le Sonatype Q2 2026 Open Source Malware Index, PyPI représente 48,5 % de toute l’activité malveillante non-npm — et le groupe derrière une grande partie de cette activité est TeamPCP, un acteur financialement motivé spécialisé dans le cloud, qui a mené la campagne supply chain en cascade la plus sophistiquée de l’histoire de PyPI.

Cet article couvre l’intégralité de cette campagne en 2026 : la chaîne de compromission originale de TeamPCP (mars 2026), l’open-source du ver Shai-Hulud (12 mai 2026) et la vague 2 explosive qui s’en est suivie, et la campagne Hades (8 juin 2026) qui a ciblé des développeurs Python en bio-informatique et en MCP (Model Context Protocol) via un mécanisme de hook .pth innovant livrant un stealer de credentials basé sur Bun. Puis ce qu’il faut faire concrètement.

Acte I : La chaîne de compromission TeamPCP (mars 2026)

Pour comprendre les vagues Shai-Hulud, il faut comprendre comment opère TeamPCP. Leur stratégie en mars 2026 est une chaîne de credentials en cascade : compromettre les outils de sécurité qui ont un accès privilégié aux pipelines CI/CD, voler les credentials que ces outils peuvent voir, et s’en servir pour backdoorer des paquets populaires.

Acte II : Le ver passe en open source (12 mai 2026)

La campagne TeamPCP de mars a alimenté quelque chose de bien plus grand : le ver Mini Shai-Hulud npm+PyPI. Dès le 29 avril 2026, TeamPCP lance une attaque de ver coordonnée ciblant simultanément npm et PyPI — une première historique. En deux semaines, 172 paquets en 404 versions malveillantes sont compromis, touchant TanStack, Mistral AI, Guardrails AI, UiPath et d’autres.

Puis, le 12 mai 2026 — un jour après le compromis massif de TanStack — TeamPCP fait quelque chose d’inédit : ils publient le code source complet du ver Shai-Hulud sur GitHub en open source, avec un bounty de 1 000 XMR pour quiconque pourrait lancer la plus grande attaque supply chain avec ce code. En 48 heures, le premier clone apparaissait. La vague 2 avait commencé.

Acte III : La campagne Hades — le problème .pth de PyPI (8 juin 2026)

Alors que la vague Shai-Hulud semblait se calmer, les chercheurs de Socket, Endor Labs et StepSecurity ont divulgué le 8 juin 2026 une nouvelle campagne techniquement plus sophistiquée : la campagne Hades. Elle ciblait un profil de victimes totalement différent : les chercheurs Python en bio-informatique et les développeurs travaillant sur le Model Context Protocol (MCP).

Six paquets Python utilisés en génomique, analyse de phénotype et graph machine learning ont été remplacés simultanément par des versions troyanisées — dont ensmallen, embiggen, pyphetools, gpsea, phenopacket-store-toolkit et ppkt2synergy. La recherche étendue de Socket a trouvé 471 artefacts au total (411 npm + 60 PyPI) sur 37 wheels PyPI, incluant des paquets à thème MCP comme langchain-core-mcp, et des typosquats comme rsquests, tlask et rlask.

Comment fonctionne le hook .pth — persistence au-delà de l’import

Ce qui rend Hades techniquement remarquable, c’est son mécanisme de livraison. Contrairement aux attaques précédentes qui nécessitaient d’importer le paquet malveillant, Hades utilise le mécanisme de fichiers .pth de Python — une fonctionnalité conçue pour étendre le chemin Python, mais capable d’exécuter du code arbitraire à chaque démarrage de Python.

# Mécanisme de livraison Hades — simplifié
# 1. Le wheel malveillant installe un fichier d’apparence innocente :
#    site-packages/ensmallen-setup.pth

# 2. Python traite TOUS les fichiers .pth de site-packages au démarrage
# 3. Le fichier .pth déclenche l’import du module malveillant

# 4. Le module télécharge le runtime JavaScript Bun
#    et exécute _index.js — stealer de credentials obfusqué
#
# Credentials cibles :
#   AWS_SECRET_ACCESS_KEY, GOOGLE_APPLICATION_CREDENTIALS
#   GITHUB_TOKEN, NPM_TOKEN, PYPI_TOKEN
#   Tokens Kubernetes, clés SSH (~/.ssh/)
#   Historique shell, fichiers .env
#   Config Docker (~/.docker/config.json)
#   Config outils IA : ~/.claude/, ~/.cursor/, ~/.gemini/

Le risque clé : une fois un paquet compromis par Hades installé dans un environnement virtuel, chaque processus Python dans ce venv exfiltre des credentials au démarrage — même les processus sans rapport avec le paquet malveillant. Le stealer s’active à chaque exécution Python dans ce venv, y compris votre test runner, vos outils de linting et vos scripts de build.

Chiffres clés 2026 pour PyPI

PyPI Trusted Publishers : La bonne architecture avec ses limites

Le système de Trusted Publishers de PyPI — basé sur des tokens OIDC plutôt que des clés API statiques — est la bonne réponse au vol de credentials. Au lieu de stocker un token statique dans les secrets CI/CD, votre workflow échange un token OIDC à courte durée contre un token d’upload PyPI valable 15 minutes. Il n’y a aucun secret à voler, faire tourner ou committer accidentellement.

Plus de 50 000 projets PyPI utilisent maintenant les Trusted Publishers, représentant plus de 20 % de tous les uploads. Mais la campagne TeamPCP a révélé des limites importantes que les développeurs doivent comprendre :

Guide de protection de vos projets Python en 2026

Etape 1 : Auditer les infections .pth maintenant

Vérifiez tous vos environnements virtuels pour des fichiers .pth suspects avant tout :

# Trouver tous les .pth suspects dans le venv actif
find $(python -c "import site; print(site.getsitepackages()[0])") \
     -name "*.pth" | xargs grep -l "import\|exec\|__import__" 2>/dev/null

# Les fichiers .pth légitimes ne contiennent que des chemins
# Tout fichier .pth avec "import" ou "exec" est suspect

Étape 2 : Lancer pip-audit sur chaque projet

# Installation
pip install pip-audit

# Audit des paquets installés (base OSV)
pip-audit

# Audit d’un requirements.txt sans installation
pip-audit -r requirements.txt

# Sortie JSON pour CI/CD
pip-audit --format=json --output=audit.json

Étape 3 : Pinner les dépendances avec des hashes

# Générer requirements.txt avec hashes d’intégrité
pip-compile --generate-hashes requirements.in > requirements.txt

# Installation avec vérification des hashes
pip install --require-hashes -r requirements.txt
# Toute altération du paquet fait échouer l’installation

Étape 4 : Activer les Trusted Publishers pour vos publiés

• Paramètres PyPI → Publishing → Ajouter un publisher OIDC
• Configurer : propriétaire GitHub + dépôt + fichier workflow + nom d’environnement
• Utiliser on: push vers une branche protégée (jamais on: pull_request seul)
• Protection de branche : review PR obligatoire, no direct push, no force-push
• Révoquer tous les tokens PyPI statiques une fois OIDC opérationnel
• 2FA obligatoire sur tous les comptes PyPI mainteneur