Nach Angaben von Oliver Jensen und Mateo Wang von LiteLLM wurde am 27. Mai 2026 eine Konfigurationsdatei in das öffentliche Repository LiteLLM-Labs/lite-harness eingecheckt, die den Master-Key einer Installation der LiteLLM Agent Platform enthielt – eines quelloffenen Werkzeugs, das das Projekt zur Orchestrierung von Agenten einsetzt. Der Fehler sei rasch bemerkt, der Commit per Force-Push überschrieben und die offengelegten Schlüssel als widerrufsbedürftig eingestuft worden. Für den Master-Key unterblieb der Widerruf jedoch.

Am 10. Oktober 2026 verschaffte sich der Angreifer – nach Darstellung des Projekts von der Adresse 69.48.229[.]143 aus – mit diesem Schlüssel Zugriff auf die Agent Platform und zog ein dort hinterlegtes OAuth-Token der GitHub CLI ab. Das Token war dafür eingerichtet, selbst gehosteten Cloud-Agenten das Einreichen von Pull Requests zu ermöglichen. Es war laut den Entwicklern des quelloffenen LLM-Gateways „nicht in seinen Rechten eingeschränkt" und gehörte zum Konto eines Organisationsinhabers – der Angreifer erlangte damit Eigentümerrechte an sämtlichen Repositories der Organisation und konnte weitere Zugangsdaten abgreifen.

Der zeitliche Ablauf stellt sich danach so dar:

    1. Oktober 2026, 22:11 bis 22:12 UTC: Commits in Wegwerf-Branches interner Repositories (BerriAI/litellm und BerriAI/litellm-auto) starten Workflows, die GitHub-CLI-OAuth-Token zweier Entwickler mit Maintainer-Rechten an einen vom Angreifer kontrollierten webhook[.]site-Endpunkt senden. Beide Läufe werden Minuten später gelöscht.
    1. Oktober 2026, 10:08 bis 11:08 UTC: Der Branch-Schutz wird ausgehebelt und die Release-Pipeline so verändert, dass als Quelle das täuschend ähnliche Repository „Berri-AI/litellm" statt „BerriAI/litellm" dient.
    1. Oktober 2026, 11:39 bis 11:40 UTC: LiteLLM 1.107.0 erscheint auf PyPI.
    1. Oktober 2026, 11:46 UTC: Veröffentlichung der Images auf Docker Hub und GHCR.
    1. Oktober 2026, 11:53 bis 11:54 UTC: Lauf-Aufzeichnungen von Produktion und Staging werden gelöscht.
    1. Oktober 2026, 12:06 UTC: Der Upwind-Forscher Lidor Machluf meldet den Supply-Chain-Angriff.
    1. Oktober 2026, 13:23 UTC: PyPI stellt Version 1.107.0 unter Quarantäne.
  • 14:20 UTC: Die Docker-Hub-Tags v1.107.0, latest, main-latest und main-stable werden entfernt oder auf verifiziert saubere Images umgebogen.

Normalerweise müsse ein Release von einem autorisierten Entwickler angestoßen und von einem Sonderkonto freigegeben werden, das an ein physisches Gerät im Büro gebunden ist, erklärte LiteLLM. Diese Einschränkung sei jedoch kurz zuvor gelockert worden, um vorübergehend häufigere Releases und Bugfix-Backports zu ermöglichen; seitdem konnten zwei beliebige Entwickler ein Release auslösen und freigeben. Der Angreifer nutzte eines der erbeuteten Token zum Auslösen – nachdem er den Deployer auf sein bösartiges Repository umgelenkt hatte – und ein zweites zur Freigabe. Die Maintainer weisen darauf hin, dass der Angreifer die Beschränkung mit dem Token eines Organisationsinhabers ohnehin selbst hätte lockern oder ganz entfernen können; vermutlich unterblieb dies, um nicht aufzufallen. Die Workflows waren zudem darauf ausgelegt, weitere Schlüssel und Token aufzuspüren, insbesondere Token für vorgelagerte Inferenz-APIs. Als Reaktion arbeitet das Unternehmen daran, sämtliche Token aller internen Systeme und Anbieterplattformen zu widerrufen.

Socket veröffentlichte eine eigene Untersuchung der bösartigen Workflows. Das Unternehmen rekonstruierte zwei Commits, die jeweils einen Workflow unter „.github/workflows/cache.yml" hinzufügten – der erste am 10. Oktober 2026 um 22:11:45 UTC, der zweite am 12. Oktober. „Keiner der beiden Commits wurde auf einen Branch gepusht, der noch existiert", sagte Socket-Sicherheitsforscher Karlo Zanki. „Beide gingen an kurzlebige Branches namens ci-tmp-<hex>, die innerhalb von Minuten angelegt, genutzt und gelöscht wurden – deshalb hinterlässt die Aktivität in der normalen Historie des Repositories fast nichts."

Der Analyse der Aktivitätsprotokolle zufolge stützten sich beide Commits auf einen legitimen Commit als Branch-Basis, damit der Push harmlos wirkt. Das Muster: Anlegen eines Wegwerf-Branches „ci-tmp-<hex>" (konkret ci-tmp-a351cc und ci-tmp-4d8517) aus einem jüngeren legitimen Commit, Push eines Commits mit der Datei „.github/workflows/cache.yml" und jeweils derselben Betreffzeile „ci: bump cache config", Auslösen des Workflows über den Trigger „on: [push]" bei jedem Commit oder Tag, anschließend Löschen des Branches.

Beide Workflows sammelten GitHub-Token sowie API-Schlüssel für den Linear-Workspace der Organisation, die LiteLLM-Installation und Together AI, dazu Kennung und Signaturschlüssel einer GitHub App. Der Lauf vom 12. Oktober erweiterte die Sammlung auf API-Schlüssel für Anthropic, OpenAI, AWS Bedrock, Tavily und den Secret-Scanning-Mandanten von GitGuardian; außerdem wurden Playwright-Storage-State, PostgreSQL-Daten (Verbindungszeichenfolge, Kontoname, Passwort) sowie Adresse, Port und Authentifizierungspasswort eines Redis-Endpunkts erfasst. Die Daten flossen an zwei webhook[.]site-Endpunkte:

  • webhook[.]site/65a42464-3cfa-4b02-a18c-17a6d7b86f37
  • webhook[.]site/4da03473-a3e7-4dc2-a087-9c564b4208e1

„Ein GitHub-Token und ein privater Schlüssel einer GitHub App sind Zugangsdaten für die Plattform, die das Repository hostet, nicht für einen Drittdienst", sagte Zanki. „GITGUARDIAN_API_KEY ist ein Zugangsdatum für die Secret-Scanning-Plattform selbst, was einem Angreifer Einblick in – und womöglich Kontrolle über – jene Warnmeldungen gibt, die diese Aktivität sichtbar machen würden." E2E_LINEAR_STORAGE_STATE_B64 sei serialisierter Browser-Sitzungszustand, den Playwright für End-to-End-Tests nutze; ein gültiger Storage State erlaube authentifizierten Zugriff auf das zugehörige Linear-Konto ohne Passwort und ohne Mehrfaktor-Authentifizierung.

Die Erkenntnisse widerlegen LiteLLMs ursprüngliche Annahme, die GitHub-CLI-OAuth-Token seien aus den Logs einer internen LiteLLM-Installation entwendet worden. „Die Untersuchung war ein Prozess, in dem wir fortlaufend Neues erfahren haben, weshalb sich einige unserer Annahmen und Überzeugungen später als ungenau oder unvollständig erwiesen", räumte Jensen ein.

Mehrere Analysen zeigen, dass die in Version 1.107.0 mitgelieferten Dateien automatisch beim Start von Python ausgeführt werden – selbst dann, wenn eine Anwendung LiteLLM gar nicht importiert. Die Schadsoftware kennt zwei Ausführungspfade: ein Modul zum Abgreifen von Zugangsdaten aus Entwicklerwerkzeugen, KI-Anwendungen, Cloud-Umgebungen und Webbrowsern sowie eine auf Unix ausgerichtete Hintertür, die als Hintergrundprozess läuft und stündlich beliebigen, vom Angreifer gelieferten Code nachlädt und ausführt.

Der Stealer sammelt zudem Systeminformationen, SSH-Dateien, Git- und GitLab-Zugangsdaten und -Token, Umgebungsvariablen sowie Token für npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems und Cargo. Die Daten werden komprimiert und per HTTP-POST an „litellm[.]dev/healthcheck" gesendet; die Domain wurde am 13. Oktober 2026 registriert.

„Zusammen weiteten diese Mechanismen die mögliche Exposition über aktive LiteLLM-Installationen hinaus aus: Allein der Start von Python in einer betroffenen Umgebung konnte den Schadcode aktivieren, selbst wenn LiteLLM nie importiert wurde", erklärte das Team von Microsoft Security Research. Da die Startdateien außerhalb des LiteLLM-Anwendungsverzeichnisses lagen, könne das bloße Entfernen der Anwendungsdateien die bösartigen Startkomponenten zurücklassen.