Behoben wurde die Schwachstelle laut den Maintainern mit der Version 1.83.7-stable, die am 19. April 2026 erschien. Der erste Ausnutzungsversuch wurde nach Angaben von Sysdig am 26. April um 16:17 UTC registriert – rund 26 Stunden und sieben Minuten, nachdem der GitHub-Advisory in der globalen GitHub Advisory Database indexiert worden war. Die SQL-Injection-Aktivität ging laut Sysdig von der IP-Adresse 65.111.27.132 aus.
Sicherheitsforscher Michael Clark beschreibt die Angriffe als zweiphasig, gesteuert vom selben Akteur über zwei benachbarte Ausgangs-IPs, gefolgt von einer kurzen nicht authentifizierten Erkundung der Schlüsselverwaltungs-Endpunkte. Der unbekannte Angreifer nahm dabei gezielt Datenbanktabellen wie „litellm_credentials.credential_values" und „litellm_config" ins Visier, die Informationen zu den Schlüsseln vorgelagerter LLM-Anbieter sowie zur Laufzeitumgebung des Proxys enthalten. Tabellen wie „litellm_users" oder „litellm_team" wurden hingegen nicht angesteuert.
Das deutet darauf hin, dass dem Angreifer diese Tabellen bekannt waren und er es gezielt auf jene abgesehen hatte, die sensible Geheimnisse enthalten. In der zweiten Phase, rund 20 Minuten später, nutzte der Akteur eine andere IP-Adresse (65.111.25.67) und führte über den erlangten Zugriff eine ähnliche Abfrage aus.
Nach Einschätzung von Sysdig ist die Tragweite besonders hoch: Eine einzelne Zeile in „litellm_credentials" enthalte häufig einen OpenAI-Organisationsschlüssel mit fünfstelligen monatlichen Ausgabegrenzen, einen Anthropic-Konsolenschlüssel mit Workspace-Administratorrechten und eine AWS-Bedrock-IAM-Zugangsdaten. Der Wirkungsradius einer erfolgreichen Datenbankextraktion liege damit näher an einer Kompromittierung des Cloud-Kontos als an einer typischen SQL-Injection in einer Webanwendung.
Das Projekt war bereits in diesem Monat Ziel eines Supply-Chain-Angriffs der Hackergruppe TeamPCP, die Zugangsdaten und Geheimnisse von nachgelagerten Nutzern entwenden wollte.
Den Nutzern wird empfohlen, ihre Instanzen auf die aktuelle Version zu aktualisieren. Ist das nicht sofort möglich, raten die Maintainer dazu, unter „general_settings" die Option „disable_error_logs: true" zu setzen, um den Pfad zu schließen, über den nicht vertrauenswürdige Eingaben die verwundbare Abfrage erreichen.
Sysdig ordnet den Fall (GHSA-r75f-5x8p-qvmc) in ein wiederkehrendes Muster bei Advisories zu KI-Infrastruktur ein: kritisch, ohne Authentifizierung ausnutzbar und in Software mit fünfstelligen Sternzahlen, der Betreiber das Zentralisieren von Cloud-Zugangsdaten anvertrauen. Das beobachtete Verhalten – wörtlich übernommene Prisma-Tabellennamen, gezieltes Ansteuern von drei Tabellen und bewusstes Durchzählen der Spalten – zeige, dass Angriffe nicht mehr auf einen öffentlichen Proof-of-Concept warteten. Der Advisory und das offene Datenbankschema reichten letztlich aus.