Der Angriff war in der Ausführung schlicht, in seiner Reichweite jedoch gravierend. Die eingeschleuste Malware sammelte gezielt SSH-Schlüssel, Cloud-Zugangsdaten der großen Anbieter, Docker-Konfigurationen und andere vertrauliche Informationen ein, die auf Entwicklermaschinen im Klartext vorliegen.
Besonders weitreichend wirkte der Kaskadeneffekt über Abhängigkeiten. Nach der GitGuardian-Analyse hätten verbreitete Pakete wie dspy (fünf Millionen Downloads pro Monat), opik (drei Millionen) und crawl4ai (1,4 Millionen) bei der Installation die Ausführung der Malware ausgelöst. So konnten Unternehmen kompromittiert werden, die LiteLLM gar nicht direkt nutzten.
Neu ist dieses Angriffsmuster nicht, nur sichtbarer. Die Shai-Hulud-Kampagnen zeigten ähnliche Methoden in größerem Maßstab. Als GitGuardian 6.943 kompromittierte Entwicklermaschinen aus jenem Vorfall untersuchte, fanden die Forscher 33.185 einzigartige Geheimnisse, von denen mindestens 3.760 noch gültig waren. Jedes gültige Geheimnis tauchte im Schnitt an rund acht verschiedenen Stellen derselben Maschine auf, und 59 Prozent der betroffenen Systeme waren CI/CD-Runner statt persönlicher Laptops.
Der Erfolg der LiteLLM-Malware beruht darauf, dass Entwicklerrechner dichte Sammelpunkte für Klartext-Zugangsdaten sind. Geheimnisse landen in Quellbäumen, lokalen Konfigurationsdateien, Debug-Ausgaben, kopierten Terminalbefehlen, Umgebungsvariablen und temporären Skripten. Sie sammeln sich in .env-Dateien an, die eigentlich nur lokal gedacht waren, und werden zum dauerhaften Bestandteil der Codebasis.
Zugangsdaten verteilen sich dabei auf vorhersehbare Pfade, an denen Malware gezielt sucht: ~/.aws/credentials, ~/.config/gh/config.yml, .env-Dateien in Projekten, die Shell-Historie und Konfigurationsverzeichnisse von Agenten. Entwickler betreiben heute Agenten, lokale MCP-Server, CLI-Werkzeuge, IDE-Erweiterungen, Build-Pipelines und Abrufprozesse, die allesamt Zugangsdaten benötigen.
GitGuardian empfiehlt, die Sicherung von Geheimnissen über Code-Repositories hinaus auf die Entwicklermaschine selbst auszudehnen. Den Anfang macht Sichtbarkeit: Mit ggshield lassen sich lokale Repositories sowie Dateipfade außerhalb von Git scannen — Projektverzeichnisse, Dotfiles, Build-Ausgaben und Agenten-Ordner, in denen lokale KI-Werkzeuge Logs, Caches und „Memory"-Speicher anlegen. Auch Shell-Profile, IDE-Einstellungen und erzeugte Artefakte können Umgebungswerte dauerhaft auf der Festplatte ablegen. Pre-Commit-Hooks von ggshield sollen verhindern, dass neue Geheimnisse in Commits gelangen.
Erkennung ohne Beseitigung bleibe jedoch wirkungslos. GitGuardian rät, Geheimnisse als verwaltete Identitäten mit klarer Zuständigkeit, Lebenszyklus-Richtlinien und automatisierten Beseitigungspfaden zu behandeln und in eine zentrale Vault-Infrastruktur zu überführen. Bei agentischen Werkzeugen im Stil von OpenClaw liegt das „Memory" buchstäblich als Dateien auf der Festplatte (SOUL.md, MEMORY.md) — Zugangsdaten sollten nie in Agenten-Chats eingefügt werden, und Agenten-Speicher seien wie sensible Datenspeicher regelmäßig zu scannen.
Den schnellsten Weg, die Verbreitung von Geheimnissen zu verringern, sieht GitGuardian darin, ganze Kategorien gemeinsam genutzter Geheimnisse überflüssig zu machen: WebAuthn (Passkeys) statt Passwörter auf der menschlichen Seite, OIDC-Föderation für Pipelines, damit diese keine gespeicherten Cloud-Schlüssel mehr benötigen. Wo sich Geheimnisse nicht beseitigen lassen, sollen sie kurzlebig und automatisch ersetzbar sein — etwa über SPIFFE, das kryptografische Identitätsdokumente (SVIDs) mit automatischer Rotation ausstellt.
Als Übergangsschutz nennt GitGuardian Honeytokens: Lockvogel-Zugangsdaten an Orten, die Angreifer gezielt durchsuchen — Heimatverzeichnisse, gängige Konfigurationspfade und Agenten-Speicher. Werden sie abgegriffen und verifiziert, lösen sie sofort Alarm aus und verkürzen die Erkennungszeit erheblich.