PyTorch Lightning : 2 versions PyPI volent vos secrets

Ce qui s'est passé

Le 30 avril 2026 à 14h12 UTC, un attaquant disposant d'identifiants PyPI valides a publié deux nouvelles versions du package lightning, l'un des paquets Python les plus téléchargés de l'écosystème machine learning avec environ 12 millions de téléchargements mensuels. Les versions 2.6.2 et 2.6.3 ressemblaient à des releases mineures, mais embarquaient un payload conçu pour exfiltrer en silence l'ensemble des secrets accessibles depuis l'hôte d'installation. Le scanner IA de Socket a flaggé les deux versions comme suspectes dix-huit minutes après leur publication, et l'équipe PyPI les a placées en quarantaine au bout de 42 minutes au total. Ce délai paraît court, mais à l'échelle du téléchargement automatique sur des CI/CD et des environnements de notebook partagés, il suffit largement à compromettre des milliers de machines.

L'attaque utilise une mécanique observée pour la première fois à grande échelle dans la campagne Shai-Hulud de septembre 2025, et que les chercheurs d'Aikido qualifient désormais de mini Shai-Hulud. Le code malveillant est injecté directement dans le fichier __init__.py du package : à chaque import lightning, le module charge un script de fond qui s'exécute silencieusement, sans aucune sortie visible et sans modifier le comportement fonctionnel du package. L'utilisateur n'a strictement aucun moyen de détecter la compromission depuis son notebook ou sa pipeline. Le malware déchiffre ensuite une seconde charge depuis une chaîne base64 embarquée et la lance via subprocess en arrière-plan.

Une fois actif, le voleur balaie le système à la recherche de tout ce qui ressemble à un secret. Sont visés en priorité les fichiers .npmrc, .pypirc, .aws/credentials, .gcp, .azure, .docker/config.json, ~/.ssh/, ainsi que les variables d'environnement contenant les chaînes TOKEN, KEY, SECRET, PASSWORD ou API. Le malware extrait également les wallets de cryptomonnaies (MetaMask, Phantom, Exodus, Atomic) en lisant directement les bases LevelDB des extensions navigateur. L'ensemble des données est exfiltré vers un endpoint webhook.site rotatif, technique qui rend le takedown beaucoup plus difficile que de cibler un domaine fixe.

La partie la plus inquiétante du payload est sa capacité d'auto-propagation. Si le malware trouve des credentials npm publish actifs sur la machine compromise, il clone chaque package que ce token a le droit de publier, injecte un script setup.mjs dropper accompagné d'un fichier router_runtime.js, configure scripts.preinstall pour exécuter le dropper à chaque installation, incrémente le numéro de patch version, et republie automatiquement le package empoisonné. C'est exactement le mécanisme viral qui avait permis à Shai-Hulud de contaminer plus de 180 packages npm en moins de 48 heures à l'automne 2025, et qui transforme un incident initial isolé en chaîne d'infection auto-soutenue.

Le vecteur d'entrée précis n'a pas encore été confirmé par Lightning AI, l'éditeur du framework. Les analyses préliminaires de Sonatype et de Socket convergent vers une hypothèse de compromission directe du compte PyPI d'un mainteneur, plutôt qu'une attaque sur le dépôt GitHub : les versions malveillantes n'ont jamais été poussées vers le dépôt source upstream et ne correspondent à aucun commit connu. L'attaquant a donc cloné le code open source localement, injecté son payload, et publié directement sur PyPI en contournant entièrement le processus de release classique. Cette technique implique soit un vol de token API PyPI, soit une faiblesse du compte mainteneur (absence de MFA matériel, phishing, ou réutilisation d'identifiants exposés dans une autre fuite).

Les équipes de Semgrep ont également constaté une variante du payload qui tente d'ouvrir une porte dérobée persistante via cron sur Linux et via schtasks sur Windows, planifiée pour réémettre une exfiltration toutes les 6 heures. Cette persistance survit à la désinstallation de Lightning et permet à l'attaquant de continuer à voler les secrets ajoutés ultérieurement à l'hôte, par exemple lors d'un nouveau provisioning d'agent CI/CD. Une analyse forensic complète de la machine est donc nécessaire, et pas seulement un pip uninstall lightning.

L'équipe PyPI a confirmé la suppression définitive des versions 2.6.2 et 2.6.3 et levé la quarantaine sur le package, autorisant à nouveau les installations de la version 2.6.1. Lightning AI a publié un avis de sécurité demandant à tous les utilisateurs ayant installé une version compromise entre 14h12 et 14h54 UTC le 30 avril de considérer leur environnement comme intégralement compromis, et de procéder à la rotation immédiate de l'ensemble des secrets accessibles depuis cette machine. Le CERT-FR a relayé cette alerte dans son bulletin du 1er mai.

Les équipes Wiz et Snyk ont publié des règles de détection permettant d'identifier les indicateurs de compromission spécifiques à cette campagne dans les logs CI/CD : appels DNS vers webhook.site, exécution de subprocess par __init__.py de Lightning, présence de processus Python orphelins après l'import. Les organisations exploitant des plateformes notebooks managées comme Databricks, SageMaker, Vertex AI ou Azure ML doivent vérifier que leurs runners n'ont pas exécuté pip install lightning==2.6.2 ou 2.6.3 dans la fenêtre concernée.

Pourquoi c'est important

La compromission de Lightning illustre la maturité atteinte par les attaques sur la supply chain Python ciblant spécifiquement l'écosystème IA. Avec 12 millions de téléchargements mensuels et une présence quasi systématique dans les pipelines de training de modèles, ce package est exactement le type de cible que les groupes d'attaquants cherchent à industrialiser. Compromettre Lightning, c'est s'ouvrir potentiellement l'accès aux clusters GPU de centaines d'entreprises tech, aux datasets propriétaires utilisés pour entraîner des modèles, et aux clés API des plateformes d'inférence. La valeur exfiltrable dépasse de loin celle d'un classique malware bancaire.

Le timing est également révélateur. Cette compromission arrive moins de 48 heures après la divulgation de CVE-2026-25874 sur LeRobot de Hugging Face, qui exposait également l'écosystème ML à un RCE non authentifié, et trois jours après la fuite de 96 Go de code par LAPSUS$ chez Checkmarx. Les attaquants semblent avoir identifié 2026 comme l'année où la chaîne d'approvisionnement IA devient leur terrain de jeu privilégié, capitalisant sur le retard structurel des éditeurs ML en matière de sécurité du build et de signature des artefacts. La très grande majorité des packages Python du domaine IA n'utilise toujours pas de signing par sigstore ou par PEP 740, malgré la disponibilité de l'infrastructure depuis fin 2024.

Pour les directions techniques, l'incident impose une révision de la politique d'installation des dépendances en environnement IA. Les pratiques courantes consistant à exécuter pip install sans pinning strict des versions, sans vérification de hash, et sans usage de proxies internes type Artifactory ou JFrog Curation, deviennent intenables. Le délai de 42 minutes entre publication et quarantaine est suffisamment court pour que les défenses traditionnelles de scan post-publication soient inopérantes : il faut désormais des défenses pré-installation, idéalement basées sur la reputation des mainteneurs et l'analyse comportementale du payload avant son exécution. Socket, Snyk et Phylum proposent ce type de garde-fou, mais leur adoption reste minoritaire dans les équipes data science qui privilégient la vélocité.

Enfin, l'auto-propagation via tokens npm trouvés sur les machines compromises souligne un effet en cascade redoutable : un développeur qui avait simplement laissé un token npm dans son .env pour un projet annexe peut, sans le savoir, devenir le vecteur d'une infection massive de l'écosystème JavaScript via les packages dont il est mainteneur. Cette logique invite à séparer strictement les environnements de travail, à utiliser des conteneurs jetables pour chaque projet, et à scoper drastiquement les permissions des tokens API persistants. La règle d'or est désormais : aucun token publish ne doit être stocké en clair sur une machine de développement non isolée.

Ce qu'il faut retenir

• Si vous avez exécuté pip install lightning==2.6.2 ou 2.6.3 entre le 30 avril 14h12 et 14h54 UTC, considérez l'environnement comme compromis et procédez à la rotation immédiate de tous les secrets exposés.
• Mettez en place une whitelist d'index Python (Artifactory, Nexus, JFrog) avec délai d'embargo minimum de 24 heures sur les nouvelles versions de packages critiques.
• Activez sur tous vos comptes PyPI mainteneurs la MFA matérielle (clé FIDO2) et bannissez les tokens API à scope global au profit de tokens projet-spécifiques.
• Auditez les agents CI/CD et notebooks managés pour détecter les appels DNS vers webhook.site et les processus Python orphelins persistants.