Le package PyPI Telnyx compromis : une autre attaque de la chaîne d'approvisionnement que vous n'aviez pas vue venir
Le 27 mars 2026, quelqu'un a exécuté pip install telnyx et ses identifiants ont été silencieusement exfiltrés vers un serveur contrôlé par l'attaquant. Aucune erreur. Aucun avertissement. Juste une installation de package de routine qui a livré un malware directement en production.
Le SDK Python telnyx — 742 000 téléchargements le mois dernier — a été compromis par un acteur de menace appelé TeamPCP. Deux versions malveillantes (4.87.1 et 4.87.2) ont été poussées sur PyPI. Dès qu'une application exécutait import telnyx, le malware s'exécutait.
Ce n'était pas un incident isolé. C'était la cinquième attaque majeure en neuf jours par le même groupe. Et si vous développez des logiciels qui dépendent de packages open source — ce qui est le cas de tout le monde — cela devrait vous inquiéter.
Ce qui est arrivé à Telnyx
Telnyx est une plateforme de communication cloud. Son SDK Python est utilisé dans les applications de téléphonie, l'automatisation des appels et l'infrastructure de messagerie. Le type de logiciel qui tourne en production, souvent avec accès à des identifiants sensibles.
L'attaquant a modifié un seul fichier — telnyx/_client.py — et a injecté 74 lignes de code malveillant. Voici ce qu'il a fait :
Sur Linux et macOS :
- Téléchargé un fichier audio
.wav depuis le serveur de l'attaquant
- Extrait un script Python caché à l'intérieur des données audio à l'aide de la stéganographie
- Collecté les clés SSH, les identifiants cloud, les variables d'environnement et l'historique du shell
- Chiffré le tout avec AES-256 et RSA-4096
- Exfiltré le paquet vers le serveur C2 de l'attaquant
Sur Windows :
- Téléchargé un fichier
.wav différent
- Décrypté un exécutable Windows caché à l'intérieur
- Déposé sous le nom
msbuild.exe dans le dossier Démarrage de Windows
- Le binaire s'exécute silencieusement à chaque connexion — accès persistant
L'astuce du .wav mérite d'être notée. La charge utile n'était pas un script ou un binaire. Elle était déguisée en fichier audio valide. Les filtres de contenu qui autorisent les téléchargements de .wav ne l'auraient pas signalée. Les données malveillantes se cachaient dans les trames audio, décodées à l'exécution à l'aide de XOR. Comme l'a noté Charlie Eriksen d'Aikido, TeamPCP a utilisé cette technique de stéganographie WAV pour la première fois le 22 mars et l'a suffisamment appréciée pour continuer à la déployer.
Cinq attaques en neuf jours : la campagne TeamPCP
Telnyx n'était pas le début. C'était le dernier domino. Voici le calendrier complet, tel que documenté par Aikido et StepSecurity :
1. Trivy — 19 mars
Le scanner de vulnérabilités open source d'Aqua Security a été compromis (CVE-2026-33634, CVSS 9.4). Chaque pipeline CI/CD exécutant Trivy sans version épinglée a vu ses identifiants exfiltrés. L'attaquant a renommé 44 dépôts GitHub d'Aqua Security avec le préfixe tpcp-docs-. Cela a donné à TeamPCP les identifiants volés dont ils avaient besoin pour tout ce qui a suivi.
2. CanisterWorm sur npm — 20 mars
En utilisant les jetons volés aux utilisateurs de Trivy, TeamPCP a publié un backdoor auto-répliquant — CanisterWorm — sur plus de 46 packages npm, y compris des scopes comme @EmilGroup et @opengov. Avec un seul jeton npm volé, le ver a énuméré tous les packages publiables, a augmenté les versions et a publié du code compromis sur l'ensemble du scope en moins de 60 secondes.
3. GitHub Actions de Checkmarx — 23 mars
Les GitHub Actions kics-github-action et ast-github-action ont été compromises, ainsi que deux extensions OpenVSX. 35 tags ont été détournés en moins de quatre heures. La charge utile utilisait un nouveau domaine C2 usurpant l'identité de la marque Checkmarx.
4. LiteLLM sur PyPI — 24 mars
LiteLLM — environ 95 millions de téléchargements par mois, largement déployé comme passerelle LLM centralisée avec accès aux identifiants pour OpenAI, Anthropic, AWS Bedrock et GCP VertexAI — a vu ses versions 1.82.7 et 1.82.8 compromises. Les identifiants ont été volés depuis le pipeline CI/CD de LiteLLM, qui exécutait Trivy sans version épinglée. PyPI a mis les packages en quarantaine après environ trois heures.
5. Telnyx sur PyPI — 27 mars
La compromission décrite ci-dessus. Même clé publique RSA-4096. Même signature d'exfiltration tpcp.tar.gz. Même schéma de chiffrement. Package différent, même stratégie.
Le schéma : Compromettre un outil de confiance → voler les identifiants de ses utilisateurs → utiliser ces identifiants pour compromettre la cible suivante → répéter.
Pourquoi les attaques de la chaîne d'approvisionnement continuent de fonctionner
Ce n'est pas nouveau. Et c'est ça le problème.
- 2024 : Le backdoor
xz-utils a failli compromettre tous les systèmes Linux de la planète via une campagne d'ingénierie sociale de plusieurs années sur un seul mainteneur.
- 2025 : Plusieurs campagnes de typosquatting sur PyPI ont ciblé des packages populaires comme
requests, boto3 et tensorflow.
- 2026 : TeamPCP mène une campagne de plusieurs semaines et multi-écosystèmes — PyPI, npm, GitHub Actions, extensions VS Code — et ils itèrent en temps réel.
La raison pour laquelle cela continue de fonctionner repose sur quelques vérités inconfortables :
1. La plupart des équipes n'épinglent pas leurs dépendances.
Exécuter pip install --upgrade telnyx le 27 mars a silencieusement téléchargé un malware. Aucun signalement. Aucune différence. Juste la dernière version, car c'est ce que "dernière" signifiait ce matin-là.
2. La chaîne d'approvisionnement n'est pas dans le modèle de menace.
La sécurité des applications se concentre sur votre code. La sécurité de l'infrastructure se concentre sur vos serveurs. Mais le code qui s'exécute dans votre environnement est majoritairement du code que vous n'avez pas écrit. La plupart des programmes de sécurité considèrent les registres de packages comme des sources fiables.
3. La détection est difficile.
TeamPCP a utilisé la stéganographie WAV, l'encodage base64, l'obfuscation XOR et des sous-processus détachés. Le malware s'exécute à l'importation, se nettoie et ne laisse aucune trace sur le disque. Les scanners de sécurité traditionnels ne détectent pas cela.
4. Le rayon d'explosion est énorme.
Un package compromis avec 742 000 téléchargements mensuels signifie des milliers d'environnements potentiellement exfiltrés avant que quiconque ne s'en aperçoive. Les 95 millions de téléchargements mensuels de LiteLLM rendent la situation encore pire.
Ce que vous devriez faire immédiatement
Si vous avez installé telnyx==4.87.1 ou telnyx==4.87.2 :
# Vérifiez votre version
pip show telnyx
# Rétrogradez immédiatement
pip install "telnyx==4.87.0"
Ensuite, faites pivoter tout : clés SSH, clés API, identifiants cloud, variables d'environnement, mots de passe de base de données — tout ce qui est accessible sur cette machine. Vérifiez les connexions sortantes vers 83.142.209.203 sur le port 8080 dans vos journaux réseau.
Sur Windows, recherchez msbuild.exe dans %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ et supprimez-le.
Pour tous les autres — les correctifs structurels :
Épinglez vos dépendances. Utilisez des fichiers de verrouillage (pip freeze, poetry.lock, package-lock.json). Ne vous laissez pas surprendre par pip install --upgrade.
Activez la vérification des hachages. pip install --require-hashes garantit que vous n'installez que l'artefact exact que vous attendez.
Auditez votre chaîne d'approvisionnement CI/CD. Si votre pipeline installe des packages, exécute des GitHub Actions ou télécharge des images de conteneurs — ce sont toutes des surfaces d'attaque. Épinglez les actions aux SHA de commit, pas aux tags de version.
Surveillez les connexions réseau anormales. Les requêtes HTTP sortantes vers des IP inattendues depuis vos serveurs de build ou d'application sont un signal d'alarme.
Utilisez des outils d'analyse de dépendances. Des services comme Aikido, StepSecurity, Socket.dev et Snyk peuvent détecter les packages compromis — parfois en quelques heures.
Supposez que vos dépendances seront compromises. Construisez votre posture de sécurité autour de cette hypothèse. L'accès avec le moins de privilèges, la segmentation réseau, la rotation des identifiants et la surveillance à l'exécution ne sont plus facultatifs.
La vue d'ensemble
TeamPCP a compromis cinq packages dans trois écosystèmes en neuf jours. Ils utilisent des techniques novatrices (stéganographie WAV), itèrent rapidement (correction de bugs entre 4.87.1 et 4.87.2) et enchaînent les identifiants entre les outils. Ce n'est pas un script kiddie. C'est un acteur de menace opérationnellement mature menant une campagne organisée.
L'écosystème open source est une infrastructure. Il alimente tout, des startups aux banques en passant par les hôpitaux. Et pour l'instant, le modèle de sécurité est fondamentalement brisé : un seul compte de mainteneur compromis ou un jeton CI/CD peut pousser un malware sur des millions de machines avant même que quiconque ne cligne des yeux.
Tant que les registres de packages, les systèmes de build et les organisations ne traiteront pas la sécurité de la chaîne d'approvisionnement comme une préoccupation de premier ordre — et non comme une réflexion après coup — nous continuerons à écrire ces articles. Et un autre package tombera.
Références
Virendra Singh Bhalothia
