Telnyx PyPI-Paket kompromittiert: Ein weiterer Supply-Chain-Angriff, den Sie nicht kommen sahen
Am 27. März 2026 führte jemand pip install telnyx aus, und seine Anmeldeinformationen wurden stillschweigend an einen vom Angreifer kontrollierten Server exfiltriert. Kein Fehler. Keine Warnung. Nur eine routinemäßige Paketinstallation, die Malware direkt in die Produktion einschleuste.
Das telnyx Python SDK – 742.000 Downloads im letzten Monat – wurde von einem Bedrohungsakteur namens TeamPCP kompromittiert. Zwei bösartige Versionen (4.87.1 und 4.87.2) wurden auf PyPI hochgeladen. In dem Moment, in dem eine Anwendung import telnyx ausführte, wurde die Malware ausgeführt.
Dies war kein Einzelfall. Es war der fünfte große Angriff innerhalb von neun Tagen durch dieselbe Gruppe. Und wenn Sie Software entwickeln, die von Open-Source-Paketen abhängt – was auf jeden zutrifft – sollte Sie das nachts wachhalten.
Was mit Telnyx geschah
Telnyx ist eine Cloud-Kommunikationsplattform. Ihr Python SDK wird in Telefonieanwendungen, Anrufautomatisierung und Messaging-Infrastrukturen eingesetzt. Die Art von Software, die in der Produktion läuft, oft mit Zugriff auf sensible Anmeldeinformationen.
Der Angreifer modifizierte eine einzelne Datei – telnyx/_client.py – und injizierte 74 Zeilen bösartigen Codes. Hier ist, was er tat:
Unter Linux und macOS:
- Eine
.wav-Audiodatei vom Server des Angreifers heruntergeladen
- Ein verstecktes Python-Skript aus den Audiodaten mittels Steganographie extrahiert
- SSH-Schlüssel, Cloud-Anmeldeinformationen, Umgebungsvariablen und Shell-Verlauf gesammelt
- Alles mit AES-256 und RSA-4096 verschlüsselt
- Das Paket an den C2-Server des Angreifers exfiltriert
Unter Windows:
- Eine andere
.wav-Datei heruntergeladen
- Eine darin versteckte Windows-Executable dekodiert
- Diese als
msbuild.exe im Windows-Autostartordner abgelegt
- Die Binärdatei läuft bei jeder Anmeldung stillschweigend – persistenter Zugriff
Der .wav-Trick ist bemerkenswert. Die Payload war kein Skript oder eine Binärdatei. Sie war als gültige Audiodatei getarnt. Inhaltsfilter, die .wav-Downloads zulassen, würden sie nicht kennzeichnen. Die bösartigen Daten versteckten sich in den Audio-Frames und wurden zur Laufzeit mittels XOR dekodiert. Wie Charlie Eriksen von Aikido feststellte, verwendete TeamPCP diese WAV-Steganographie-Technik erstmals am 22. März und fand sie gut genug, um sie weiterhin einzusetzen.
Fünf Angriffe in neun Tagen: Die TeamPCP-Kampagne
Telnyx war nicht der Anfang. Es war der jüngste Dominostein. Hier ist der vollständige Zeitplan, wie er von Aikido und StepSecurity dokumentiert wurde:
1. Trivy – 19. März
Der Open-Source-Schwachstellenscanner von Aqua Security wurde mit einer Backdoor versehen (CVE-2026-33634, CVSS 9.4). Jede CI/CD-Pipeline, die Trivy ohne Versionsfixierung ausführte, hatte Anmeldeinformationen exfiltriert. Der Angreifer benannte 44 GitHub-Repositories von Aqua Security mit dem Präfix tpcp-docs- um. Dies verschaffte TeamPCP die gestohlenen Anmeldeinformationen, die sie für alles Folgende benötigten.
2. CanisterWorm auf npm – 20. März
Mit von Trivy-Benutzern gestohlenen Tokens veröffentlichte TeamPCP eine sich selbst replizierende Backdoor – CanisterWorm – über mehr als 46 npm-Pakete, einschließlich Scopes wie @EmilGroup und @opengov. Mit einem gestohlenen npm-Token enumerierte der Wurm alle veröffentlichbaren Pakete, erhöhte die Versionen und veröffentlichte kompromittierten Code im gesamten Scope in weniger als 60 Sekunden.
3. Checkmarx GitHub Actions – 23. März
Die GitHub Actions kics-github-action und ast-github-action wurden kompromittiert, zusammen mit zwei OpenVSX-Erweiterungen. 35 Tags wurden in weniger als vier Stunden gekapert. Die Payload verwendete eine neue C2-Domain, die die Marke Checkmarx imitierte.
4. LiteLLM auf PyPI – 24. März
LiteLLM – etwa 95 Millionen Downloads pro Monat, weit verbreitet als zentralisiertes LLM-Gateway mit Zugriff auf Anmeldeinformationen für OpenAI, Anthropic, AWS Bedrock und GCP VertexAI – hatte die Versionen 1.82.7 und 1.82.8 kompromittiert. Die Anmeldeinformationen wurden aus der CI/CD-Pipeline von LiteLLM gestohlen, die ungepinntes Trivy ausführte. PyPI isolierte die Pakete nach etwa drei Stunden.
5. Telnyx auf PyPI – 27. März
Die oben beschriebene Kompromittierung. Derselbe RSA-4096-Public-Key. Dieselbe tpcp.tar.gz-Exfiltrationssignatur. Dasselbe Verschlüsselungsschema. Anderes Paket, gleiches Vorgehen.
Das Muster: Ein vertrauenswürdiges Tool kompromittieren → Anmeldeinformationen von seinen Benutzern stehlen → diese Anmeldeinformationen verwenden, um das nächste Ziel zu kompromittieren → wiederholen.
Warum Supply-Chain-Angriffe immer wieder funktionieren
Das ist nicht neu. Und das ist das Problem.
- 2024: Die
xz-utils-Backdoor kompromittierte fast jedes Linux-System auf dem Planeten durch eine jahrelange Social-Engineering-Kampagne gegen einen einzelnen Maintainer.
- 2025: Mehrere PyPI-Typosquatting-Kampagnen zielten auf beliebte Pakete wie
requests, boto3 und tensorflow ab.
- 2026: TeamPCP führt eine mehrwöchige, ökosystemübergreifende Kampagne durch – PyPI, npm, GitHub Actions, VS Code-Erweiterungen – und sie iterieren in Echtzeit.
Der Grund, warum dies immer wieder funktioniert, liegt in einigen unangenehmen Wahrheiten:
1. Die meisten Teams fixieren Abhängigkeiten nicht.
Das Ausführen von pip install --upgrade telnyx am 27. März zog stillschweigend Malware. Keine Flagge. Kein Diff. Nur die neueste Version, denn das war es, was "latest" an diesem Morgen bedeutete.
2. Die Lieferkette ist nicht im Bedrohungsmodell enthalten.
Die Anwendungssicherheit konzentriert sich auf Ihren Code. Die Infrastruktursicherheit konzentriert sich auf Ihre Server. Aber der Code, der in Ihrer Umgebung läuft, ist überwiegend Code, den Sie nicht geschrieben haben. Die meisten Sicherheitsprogramme behandeln Paketregister als vertrauenswürdige Quellen.
3. Die Erkennung ist schwierig.
TeamPCP verwendete WAV-Steganographie, Base64-Kodierung, XOR-Verschleierung und abgetrennte Subprozesse. Die Malware läuft zur Importzeit, räumt sich selbst auf und hinterlässt keine Artefakte auf der Festplatte. Herkömmliche Sicherheitsscanner erkennen dies nicht.
4. Der Explosionsradius ist massiv.
Ein kompromittiertes Paket mit 742.000 monatlichen Downloads bedeutet, dass Tausende von Umgebungen potenziell exfiltriert werden, bevor es jemand bemerkt. Die 95 Millionen monatlichen Downloads von LiteLLM machen es noch schlimmer.
Was Sie jetzt tun sollten
Wenn Sie telnyx==4.87.1 oder telnyx==4.87.2 installiert haben:
# Überprüfen Sie Ihre Version
pip show telnyx
# Sofort downgraden
pip install "telnyx==4.87.0"
Dann alles rotieren: SSH-Schlüssel, API-Schlüssel, Cloud-Anmeldeinformationen, Umgebungsvariablen, Datenbankpasswörter – alles, was auf dieser Maschine zugänglich ist. Überprüfen Sie Ihre Netzwerkprotokolle auf ausgehende Verbindungen zu 83.142.209.203 auf Port 8080.
Unter Windows suchen Sie nach msbuild.exe in %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ und löschen Sie es.
Für alle anderen – die strukturellen Korrekturen:
Fixieren Sie Ihre Abhängigkeiten. Verwenden Sie Lock-Dateien (pip freeze, poetry.lock, package-lock.json). Lassen Sie sich nicht von pip install --upgrade überraschen.
Aktivieren Sie die Hash-Verifizierung. pip install --require-hashes stellt sicher, dass Sie nur das genaue Artefakt installieren, das Sie erwarten.
Überprüfen Sie Ihre CI/CD-Lieferkette. Wenn Ihre Pipeline Pakete installiert, GitHub Actions ausführt oder Container-Images zieht – das sind alles Angriffsflächen. Fixieren Sie Aktionen auf Commit-SHAs, nicht auf Versionstags.
Überwachen Sie anomale Netzwerkverbindungen. Ausgehende HTTP-Verbindungen zu unerwarteten IPs von Ihren Build- oder Anwendungsservern sind ein Warnsignal.
Verwenden Sie Tools zur Abhängigkeitsscannung. Dienste wie Aikido, StepSecurity, Socket.dev und Snyk können kompromittierte Pakete erkennen – manchmal innerhalb weniger Stunden.
Gehen Sie davon aus, dass Ihre Abhängigkeiten kompromittiert werden. Bauen Sie Ihre Sicherheitslage auf dieser Annahme auf. Least-Privilege-Zugriff, Netzwerksegmentierung, Anmeldeinformationsrotation und Laufzeitüberwachung sind keine optionalen Maßnahmen mehr.
Das größere Bild
TeamPCP kompromittierte fünf Pakete in drei Ökosystemen innerhalb von neun Tagen. Sie verwenden neuartige Techniken (WAV-Steganographie), iterieren schnell (beheben Fehler zwischen 4.87.1 und 4.87.2) und verketten Anmeldeinformationen über Tools hinweg. Dies ist kein Skript-Kiddie. Dies ist ein operativ reifer Bedrohungsakteur, der eine organisierte Kampagne durchführt.
Das Open-Source-Ökosystem ist Infrastruktur. Es treibt alles an, von Startups über Banken bis hin zu Krankenhäusern. Und im Moment ist das Sicherheitsmodell grundlegend fehlerhaft: Ein einziges kompromittiertes Maintainer-Konto oder CI/CD-Token kann Malware auf Millionen von Maschinen verteilen, bevor jemand blinzelt.
Solange Paketregister, Build-Systeme und Organisationen die Sicherheit der Lieferkette nicht als erstklassiges Anliegen behandeln – und nicht als nachträglichen Einfall – werden wir diese Beiträge weiterhin schreiben. Und ein weiteres Paket wird untergehen.
Referenzen
Virendra Singh Bhalothia
