Die Sicherheitsforscher des Cloud-Security-Unternehmens Sysdig dokumentierten eine koordinierte Angriffskampagne, die bereits 36 Stunden nach der öffentlichen Bekanntmachung der Lücke am 24. April begann. Die Attacken zeigen professionelle Handschrift: Angreifer sendeten gezielt manipulierte HTTP-Header mit SQL-Injection-Payloads an die ‘/chat/completions’-Route und zielten mit beeindruckender Präzision auf die Tabellen ab, in denen API-Schlüssel und Provider-Credentials gespeichert sind.
Was die Sysdig-Analysten besonders beunruhigt: Es gab keine Explorationsversuche auf harmlosen Tabellen. Der Angreifer “ging direkt zu den Geheimnissen”, was darauf hindeutet, dass die Täter genau wussten, worauf sie hinarbeiteten. In einer zweiten Angriffsphase wechselten die Attackierenden ihre IP-Adresse — ein klassisches Evadierungs-Manöver — und verfeinerten ihre Payloads basierend auf den in Phase eins gewonnenen Informationen über die exakte Tabellenstruktur.
Die Schwachstelle selbst ist technisch simpel, aber verheerend: Sie entsteht bei der API-Key-Verifizierung, wo LiteLLM ursprünglich String-Konkatenation statt parametrisierter SQL-Queries nutzte. Ein Angreifer kann durch eine manipulierte “Authorization: Bearer”-Kopfzeile die SQL-Logik unterbrechen und beliebige Datenbankabfragen einschleusen — ohne sich jemals authentifizieren zu müssen.
Die Patch-Version 1.83.7 behebt das Problem durch die Umstellung auf parametrisierte Queries. Allerdings warnen die Sysdig-Forscher deutlich: Jede LiteLLM-Instanz, die noch die verwundbare Version nutzt, sollte als potenziell kompromittiert behandelt werden. Alle virtuellen Keys, Master-Keys und Provider-Credentials müssen sofort rotiert werden.
Die Situation wird zusätzlich durch eine jüngste Supply-Chain-Attack kompliziert: Die Hacker-Gruppe TeamPCP injizierte Malware in PyPI-Pakete und verteilte einen Credential-Stealer. Dies verdeutlicht, dass das LiteLLM-Ökosystem mehrfach unter Beschuss steht.
Für Unternehmen, die nicht sofort auf Version 1.83.7 upgraden können, bieten die Maintainer einen Workaround: Das Deaktivieren von Error-Logs unter ‘disable_error_logs: true’ in den General-Settings kann den Angriffskanal ersticken.
Das Timing und die Gezielheit dieser Exploitation unterstreichen einen besorgniserregenden Trend: Kritische Schwachstellen in beliebten Open-Source-KI-Tools werden innerhalb von eineinhalb Tagen ausgebeutet. Für Organisations-Sicherheitsteams bleibt nur ein klares Gebot: Patchen, Rotieren, Monitoren.