GitHub, PyPI, depuis plusieurs mois, les attaques contre la chaîne d’approvisionnement logicielle explosent. Et contrairement à l’image romantique du hacker barbu dans un garage, ces nouvelles menaces sont bien plus subtiles : elles se glissent dans les outils qu’on utilise tous les jours, ceux qu’on installe sans lire, ceux qu’on clone sans vérifier. Derniers exemples en date : PyPI et GitHub, devenus les terrains de jeu favoris des cybercriminels.
« Open source » ne veut pas dire « open bar » pour les malwares.
Dans cet article, on passe en revue deux campagnes récentes dévoilées par Trend Micro, ReversingLabs et d’autres chercheurs, pour comprendre pourquoi le code que vous utilisez n’est peut-être pas celui que vous croyez.
🌐 Partie 1 : PyPI, ou le pip install qui installe un trojan
En juin 2025, plusieurs packages Python disponibles sur le dépôt officiel PyPI ont été identifiés comme malveillants :
pyobfs: package soi-disant utile pour l’obfuscation de codeaiohttpx: version piégée d’un wrapper async populairecolorama-plus: un faux « add-on » à Colorama
Le point commun ? Tous embarquaient des scripts d’installation (à base de setup.py, __init__.py, ou postinstall) qui exécutaient du code malveillant au moment de l’installation. Certaines charges tentaient de :
- Voler les identifiants stockés localement
- Installer un RAT (Remote Access Trojan)
- Exfiltrer des tokens (Discord, GitHub, AWS…)
La beauté du geste ? Aucune alerte à l’installation. Le code s’exécute « comme prévu ».
⚡ Pourquoi c’est dangereux
- PyPI est utilisé dans les scripts automatisés, les Dockerfiles, les CI/CD pipelines
pip installest souvent exécuté avec des privilèges élevés (root, sudo)- Les scripts d’installation sont rarement audités
D’ailleurs on en parlait lundi pur ceux qui dormaient : « Chimera, mais en réalité Chimère » : quand un paquet PyPI se prend pour un help‑dev et finit en Robin des Secrets
🔓 Partie 2 : GitHub, repo communautaire ou repo d’infection ?
Pendant ce temps, GitHub est devenu la nouvelle autoroute à malware. Trend Micro et ReversingLabs ont mis au jour plus de 100 comptes GitHub frauduleux diffusant des outils « open source » dédiés au pentest, mais piégés avec du code malveillant :
RedTeamToolkitBruteForceXosint-suite- Et bien d’autres, souvent clonés d’un vrai projet, puis modifiés discrètement
Le malware est injecté via :
- Des scripts PowerShell ou Bash
- Des DLL ou des payloads binaires
- Des actions GitHub configurées pour lancer du code lors d’un fork ou d’un merge
🚫 Concrètement, que fait le malware ?
- Crée une persistance sur le système
- Récupère des cookies, sessions, tokens
- Se connecte à un C2 (Command & Control)
Et là aussi, tout semble propre : une jolie README, des badges, un historique de commit simulé… à moins d’être très attentif, le projet semble tout à fait légitime.
⚖ GitHub vs PyPI : même combat, mécanique différente
| Plateforme | Méthode | Impact |
|---|---|---|
| PyPI | Scripts malveillants à l’installation | Exécution à l’import ou au pip install, souvent avec droits élevés |
| GitHub | Repos infectés avec charge virale | Exécution lors de la compilation, du build ou via une action GitHub |
Dans les deux cas :
- L’utilisateur est complice involontaire de l’infection
- La charge utile se glisse dans les processus de dev et prod
- La confiance dans les sources communautaires est exploitée
📄 Qui est concerné ?
- Les devs Python, qui ajoutent des dépendances sans les vérifier
- Les admins DevOps, qui clonent des outils GitHub dans des scripts
- Les analystes sécurité, qui testent des outils de pentest piégés dans leurs labs
- Les pipelines CI/CD, où des imports automatiques s’exécutent sans validation
Spoiler : si vous avez un requirements.txt rempli de noms exotiques, vous êtes peut-être déjà infecté.
🚑 Mesures de survie
Pour PyPI
- Utiliser des outils comme pip-audit, Safety ou Poetry pour scanner les dépendances
- Bannir les paquets avec moins de X téléchargements / peu de versions
- Vérifier le code de
setup.pyet__init__.py
Pour GitHub
- Scanner les repos avant clone avec Trivy, Gitleaks, Checkov
- Désactiver l’exécution automatique de scripts post-clone
- Mettre en sandbox les environnements de test
Pour tous
- Instaurer une politique de signature de code ou de vérification cryptographique
- Éduquer les développeurs : GitHub = vecteur d’infection potentiel
- Créer des règles de firewall/DNS pour bloquer les connexions suspectes C2 sortantes
🤦_Conclusion : « community-maintained » ne veut pas dire « safe »
Le code communautaire, c’est comme une invitation à manger un plat qu’on vous offre dans la rue. Parfois, c’est un délice. Parfois, c’est un sandwich à la salmonelle.
Les cas PyPI et GitHub de 2025 montrent à quel point la confiance implicite dans les dépôts open source est devenue une faille systémique. La menace n’est plus dans un fichier .exe ou un .doc piégé. Elle est dans pip install, git clone et tous les raccourcis pratiques qu’on prend tous les jours.
Et si vous pensez encore que votre environnement de dev est à l’abri… c’est probablement déjà trop tard.
