Auf den Punkt: Angreifer kompromittieren gezielt PyPI-Pakete in KI-Toolchains, weil dort Modellgewichte, Cloud-Token und CI/CD-Secrets gebündelt an einer einzigen Stelle abgreifbar sind.
Am 24. März 2026 kompromittierte die Gruppe TeamPCP die PyPI-Distribution von LiteLLM, einem Python-Paket mit 95 Millionen monatlichen Downloads, und verteilte darüber Schadcode. Der Vorfall steht exemplarisch für eine Serie von Angriffen, die gezielt auf KI-Entwicklungsumgebungen abzielen.
TeamPCP verschaffte sich Zugriff auf die Publishing-Credentials des LiteLLM-Maintainers und veröffentlichte die manipulierten Versionen 1.82.7 und 1.82.8. Als Payload diente eine .pth-Datei – ein wenig bekannter Python-Mechanismus, der bei jedem Interpreter-Start automatisch Code ausführt, ohne dass ein expliziter Import nötig ist. Laut Zscaler ThreatLabz standen die vergifteten Pakete rund drei Stunden zur Verfügung, bevor sie unter Quarantäne gestellt wurden – Zeit genug, um nach Angaben der Quelle Zehntausende Unternehmensumgebungen zu erreichen. Der mehrstufige Payload zielte auf AWS-, GCP- und Azure-Token, SSH-Schlüssel sowie Cloud-Account-Credentials ab. Die Kampagne beschränkte sich laut ReversingLabs nicht auf LiteLLM: Zuvor kompromittierte TeamPCP bereits vertrauenswürdige Open-Source-Sicherheitswerkzeuge wie Aquas Trivy und Checkmarx KICS, bevor sie in KI-Infrastrukturbibliotheken auf PyPI wechselte. Ende April 2026 wurden zudem in PyTorch Lightning, Versionen 2.6.2 und 2.6.3, Credential-Stealing-Malware gefunden, die beim Import ausgeführt wurde; eine einzelne bösartige Workflow-Datei legte Secrets über komplette CI/CD-Pipelines offen. ReversingLabs beziffert den Anstieg bösartiger Open-Source-Pakete im Jahr 2026 auf 73 Prozent.
Für CISOs verschärft sich damit ein bekanntes Risiko in einem spezifischen Umfeld: KI- und ML-Entwicklungsumgebungen vermischen Entwicklung, Forschung, Cloud-Infrastruktur, Datenzugriff, Modell-Publishing und Automatisierung im selben Workspace. Ein kompromittiertes Python-Paket in einer gewöhnlichen Webanwendung stiehlt im schlimmsten Fall ein Datenbank-Credential. Dieselbe Attacke in einer KI-Entwicklungsumgebung kann gleichzeitig Modellgewichte, Trainingsdaten, Cloud-Token mehrerer Anbieter, CI/CD-Pipeline-Secrets und Produktions-API-Keys offenlegen – ausgehend von einer einzigen infizierten Abhängigkeit. Hinzu kommt ein Angriffsvektor namens Slopsquatting: KI-Coding-Assistenten schlagen häufig pip-install-Befehle und Import-Anweisungen für bestimmte Pakete vor. Vertraut ein Entwickler dieser Empfehlung und hat ein Angreifer bereits ein bösartiges Paket unter dem entsprechenden – teilweise vom LLM halluzinierten – Namen registriert, gelingt der Angriff ohne jede direkte Interaktion mit dem Entwickler. Untersuchungen an fast 200.000 Python-Prompts zeigten laut Quelle, dass jedes große LLM Paketnamen halluziniert, die auf PyPI nicht existieren, wodurch eine dauerhafte, durch einzelne Modell-Updates nicht vollständig zu schließende Angriffsfläche entsteht.
Als konkrete Sofortmaßnahme nennt der Artikel das Pinning von Abhängigkeiten: Statt lockerer Versionsangaben wie requests>=2.0 sollte jede Abhängigkeit in KI-Entwicklungsumgebungen auf eine exakte Version fixiert und deren Checksumme gegen einen bekannten Hash verifiziert werden. Dies allein hätte im LiteLLM-Fall den Schaden auf Umgebungen begrenzt, die aktiv auf die kompromittierten Versionen aktualisiert haben, statt jede Umgebung zu treffen, die pip install litellm ohne Versionsbindung ausführte. Als zweite Maßnahme wird das Auditing von Post-Install-Hooks in der Entwicklungspipeline genannt, da über solche Hooks – wie im LiteLLM-Fall über den .pth-Mechanismus – Code ohne expliziten Import automatisch ausgeführt werden kann.
Quelle: www.csoonline.com · Erschienen 7. August 2026
Lumi AI News — KI-assistierte Kuratierung gemaess Art. 50 EU AI Act. Paraphrase und Klassifikation durch Lumi News Pipeline v1.8.3.