Ein manipuliertes Bauteil im KI-Baukasten und die Zugangsdaten sind weg

Rund 40 Minuten standen die beiden manipulierten Pakete auf dem Paketverzeichnis, und diese 40 Minuten haben gereicht.

Was in den 40 Minuten passiert ist

Betroffen sind laut CloudSEK zwei Veröffentlichungen von LiteLLM auf PyPI, dem Paketverzeichnis für Python-Software: die Versionen 1.82.7 und 1.82.8. LiteLLM ist ein weit verbreiteter Baustein, über den eine Anwendung verschiedene Sprachmodelle unter einer einheitlichen Schnittstelle anspricht. Wer mehrere Modelle nebeneinander betreibt und sie tauschen können will, ohne die eigene Software jedes Mal umzubauen, landet mit hoher Wahrscheinlichkeit bei einem solchen Baustein.

Danach waren die beiden Versionen wieder entfernt.

In der Zwischenzeit lief laut Bericht Schadcode mit, sobald Python startete. Er umging damit die übliche Schutzoption, mit der sich Installationsskripte abschalten lassen. Abgegriffen wurden nach Darstellung von CloudSEK SSH-Schlüssel, Zugangsdaten für AWS, Google Cloud und Azure, Kubernetes-Token, Geheimnisse und Umgebungsvariablen aus Bau-Ketten sowie Schlüssel und Konfiguration von KI-Diensten. Die Daten wurden verschlüsselt abgezogen, teils in öffentliche Ablagen innerhalb der Konten der Betroffenen selbst.

Der Einstieg lag eine Stufe vorher

In die Bau-Kette von LiteLLM führte der Weg über ein anderes Werkzeug. Ein Sicherheitsscanner, der dort mitlief, war selbst kompromittiert, erreicht über ein abgeflossenes Automatisierungs-Token. Über diesen vergifteten Scanner gelangten die manipulierten Veröffentlichungen anschließend auf PyPI. Den Zeitpunkt der Manipulation datiert CloudSEK auf März 2026, zugeschrieben wird sie einer Gruppe, die als TeamPCP geführt wird.

Aufgebrochen hat die Kette also ausgerechnet ein Prüfwerkzeug für Sicherheit.

Über die Qualität von LiteLLM als Projekt sagt der Vorgang wenig. Wer eine Software baut, baut auch eine Bau-Kette drumherum, und in dieser Kette hängen Werkzeuge, die niemand als Angriffsfläche im Blick hat, weil sie ja gerade zum Prüfen da sind.

Was die Zahlen aussagen und was nicht

In einer rekonstruierten Auswertung nennt CloudSEK über 2.500 Firmen und rund 434.000 Bau-Ketten als potenziell betroffen. Die Einordnung dazu stammt von CloudSEK selbst und gehört untrennbar zu den Zahlen: Beschrieben wird eine rekonstruierte mögliche Betroffenheit, nicht eine bestätigte Übernahme. Treffer sind als hohe Übereinstimmung eingestuft, was nach Angabe des Berichts ausdrücklich kein Nachweis einer erfolgreichen Kompromittierung ist. Die Empfehlung lautet, einen Eintrag so lange als möglicherweise betroffen zu behandeln, bis eine eigene Prüfung etwas anderes ergibt.

Namen einzelner Firmen stehen in diesem Artikel deshalb nicht. Eine hohe Übereinstimmung in einer Auswertung belegt für keinen einzelnen Betrieb, dass dort tatsächlich etwas abgeflossen ist.

Für den einzelnen Betrieb zählt am Ende die eigene Prüfung. Wurde eine der beiden Versionen im März überhaupt eingesetzt, und hatte der Prozess, der sie ausgeführt hat, Zugriff auf produktive Zugangsdaten? Diese Frage lässt sich im eigenen Haus beantworten. Eine Auswertung von außen kann sie nicht beantworten.

Die ersten 24 Stunden nach der Empfehlung des Berichts

Drei Schritte nennt CloudSEK für die ersten 24 Stunden: ermitteln, ob die betroffenen Versionen im Haus verwendet wurden, betroffene Ausführungsumgebungen abtrennen und jede Zugangsberechtigung wechseln, auf die der betroffene Prozess Zugriff hatte. Gemeint sind Cloud-Konten, Code-Ablagen, Paketverzeichnisse, Kubernetes und die Schlüssel für KI-Dienste.

Am dritten Punkt hakt es in kleinen Betrieben.

Ein Schlüssel, der vor Monaten einmal in eine Konfiguration geschrieben wurde und seitdem stillschweigend seinen Dienst tut, steht in keiner Liste. Das FBI hat im Juli 2026 eine FLASH-Warnung herausgegeben, wonach gestohlene Zugangsdaten weiterhin für Angriffe verwendet werden können. Ein Zugang, der im März abgeflossen ist, funktioniert Monate später noch, wenn ihn niemand gewechselt hat. Für einen Betrieb ohne Übersicht über seine eigenen Schlüssel beschreibt die 24-Stunden-Frist aus dem Bericht in Wahrheit eine Aufgabe für zwei Wochen.

Unsere Einschätzung

Wer KI im eigenen Haus betreibt, statt sie als fertigen Dienst einzukaufen, übernimmt damit eine Lieferkette aus fremden Bausteinen, die er nie einzeln geprüft hat.

Das ist kein Argument gegen quelloffene Software. Dieselbe Abhängigkeit besteht beim eingekauften Dienst, sie ist dort nur nicht sichtbar. Unangenehm an diesem Fall ist das Tempo: 40 Minuten sind zu kurz, als dass ein Mensch etwas bemerkt, und lang genug für eine Bau-Kette, die nachts mehrfach durchläuft und jedes Mal die aktuelle Version zieht. Wer seine Abhängigkeiten auf feste Versionen festnagelt, verkleinert das Zeitfenster erheblich. Wer sie offen lässt, hält es dauerhaft offen. Bei Betrieben, die ihre ersten KI-Anwendungen selbst betreiben, sehen wir meist dasselbe Bild: Es existiert eine Liste der eingesetzten Werkzeuge, aber keine Liste der ausgegebenen Schlüssel. Gefragt wird nach der Technik, geplant wird der Betrieb, und der Punkt, wie man einen Zugang wieder einzieht, kommt in keinem Konzept vor.

Wer ohnehin nachhält, welches Modell über welchen Zugang läuft und was es kostet, hat einen Teil dieser Arbeit bereits erledigt, weil eine solche Übersicht beim Betrieb eigener KI-Zugänge genau die Liste erzeugt, die im Ernstfall gebraucht wird.

Der Test dafür kostet eine Stunde und keinen Cent. Einen produktiven Schlüssel wechseln und schauen, was danach stehen bleibt. Wenn niemand sagen kann, an welchen Stellen er überall eingetragen ist, ist das die Antwort auf die Frage, wie gut der Betrieb auf so einen Vorfall vorbereitet wäre. Und diese Antwort bekommt man lieber an einem ruhigen Dienstagvormittag als an dem Tag, an dem ein Bericht mit sechsstelligen Zahlen erscheint.

Quellen

Die genannten Angaben stützen sich auf folgende öffentlich zugängliche Quellen (Stand der Recherche: 13. August 2026):

• CloudSEK: 2,500+ Companies and 434,000 CI/CD Pipelines Exposed
• CX Today: Supply Chain Attack Exposes 2,500+ Companies
• PSU Connect: 2,500 organisations identified in the biggest AI supply chain exposure

Häufige Fragen

Zuletzt aktualisiert: 13. August 2026. Stand der Recherche: 13. August 2026.