LONDON (IT BOLTWISE) – Bei LiteLLM führte ein versehentlich veröffentlichter Master-Key dazu, dass Angreifer später einen OAuth-Token eines GitHub-Organisationsinhabers erbeuteten. Damit manipulierten sie am 21. Oktober 2026 gezielt die Release-Pipeline und stellten eine präparierte Version von LiteLLM bei PyPI sowie Container-Images bereit. Die Maintainer konnten die betroffenen Schlüssel zwar identifizieren, doch die Revokation des Master-Keys blieb offenbar aus. Offen bleibt, wie viele weitere Secrets die präparierten Workflows zusätzlich abgefischt haben und wie konsequent die Token-Kette danach in allen Systemen ersetzt wurde.
Der Fall wirkt auf den ersten Blick wie ein klassisches Supply-Chain-Problem: Ein beliebtes Python-Paket wurde kompromittiert und erst danach durch Quarantäne- und Bereinigungsmaßnahmen eingedämmt. Bei LiteLLM ist die Story allerdings vor allem deshalb so brisant, weil der eigentliche Hebel nicht beim Paket-Builder selbst lag, sondern bei einem Zugangsschlüssel, der Anfang der Attackenkette unabsichtlich im Projekt-Umfeld offen lag. LiteLLM berichtet, dass ein „Agent Platform master key“ Ende Mai 2026 in einem öffentlichen GitHub-Repository veröffentlicht wurde und später als Startpunkt diente, um in eine hochprivilegierte Berechtigungs- und Release-Kette einzudringen.
In der Darstellung der Projektverantwortlichen begann der technische Fehler am 27. Mai 2026: Ein Konfigurationsfile wurde in das öffentliche Repository „LiteLLM-Labs/lite-harness“ eingecheckt und enthielt den Master-Key für eine Deployment-Instanz der LiteLLM Agent Platform, eines Open-Source-Werkzeugs zur Orchestrierung von „Agents“. Oliver Jensen und Mateo Wang halten fest: „The error was quickly identified, the commit force-pushed over, and we identified the exposed keys as requiring revocation. However, key revocation did not occur for the master key.“ Genau dieser Punkt macht den Unterschied zwischen einem kurzfristigen Leak und einer später wirkenden Kompromittierung: Der Master-Key wurde offenbar nicht konsequent entzogen, während der Rest der Aktion – also der fehlerhafte Commit – zwar korrigiert wurde.
Am 10. Oktober 2026 nutzte ein Angreifer, der sich der Quelle zufolge über die IP 69.48.229[.]143 identifizieren ließ, den unrevoked Master-Key. Mit dem Zugriff auf die Agent Platform gelang es ihm, einen GitHub CLI OAuth-Token zu extrahieren, der für Self-hosted Cloud Agents so konfiguriert war, dass diese Pull Requests in GitHub-Repositories anstoßen konnten. Entscheidend ist die Token-Breite: LiteLLM beschreibt den Umstand, dass der Token nicht „scoped down“ war und dem Besitzerkonto der GitHub-Organisation zugeordnet blieb. Dadurch bekam der Angreifer Owner-Level-Zugriff auf alle Repositories der Organisation und konnte im Anschluss weitere Credentials exfiltrieren. Zudem schildern die Maintainer die Release-Umstände deutlich konkret: „In typical operation, building and publishing a release requires being kicked off by an authorized engineer and being approved by a special account locked to a physical device in our office.“ Diese physisch gebundene Freigabelogik wurde in der Woche zuvor offenbar vorübergehend gelockert, um häufigere Releases sowie Backports für Fehlerkorrekturen zu ermöglichen.
Mit dem tokenbasierten Zugriff griff der Angreifer dann in die Zeitachse des Release-Systems ein. Zwischen 10:11 und 10:12 Uhr UTC am 10. Oktober 2026 sollen Autorenskripte in kurzlebigen „throwaway“-Branches Workflows gestartet haben, deren Zweck es war, GitHub CLI Oauth-Tokens mehrerer Engineers mit Maintainer-Rechten via einen attacker-controlled webhook[.]site endpoint zu gewinnen; danach wurden die Läufe und Branches wenige Minuten später entfernt. Am 21. Oktober 2026 wurde anschließend Branch-Protection überschrieben und die Release-Pipeline so geändert, dass als Quell-Repository eine „Lookalike“-Variante verwendet wurde: Statt BerriAI/litellm sollte offenbar Berri-AI/litellm eingesetzt werden. In der Folge gelang die Veröffentlichung: Gegen 11:39 bis 11:40 Uhr UTC ging LiteLLM Version 1.107.0 bei PyPI online, kurz danach wurden Container-Images bei Docker Hub und GHCR veröffentlicht. Zwischenzeitlich wurden zudem Run-Records aus Produktion und Staging gelöscht, bevor später am 1:23 Uhr UTC PyPI die Version in Quarantäne nahm.
Technisch offenbart ein weiterer Untersuchungsbericht, wie die bösartigen Workflows die eigentliche Geheimnisernte betrieben. Socket beschreibt, dass zwei schadhafte Commits jeweils Workflows in der Datei „.github/workflows/cache.yml“ hinzufügten; der erste wurde am 10. Oktober 2026 um 10:11:45 Uhr UTC gesetzt, der zweite am 12. Oktober. Laut dem Security Researcher Karlo Zanki wurden beide Commits nicht in existierende Branches gespielt, sondern in kurzlebige, nach dem Muster „ci-tmp-“ benannte Branches, die innerhalb weniger Minuten erzeugt, genutzt und wieder gelöscht wurden. Dadurch blieb in der üblichen Repository-Historie kaum verwertbares Material zurück. Zankis Kernbeobachtung lautet, dass die Angreifer den Push auf eine legitime Basis gesetzt hätten, sodass der Vorgang oberflächlich harmlos wirkte, und dass der Workflow „every time a commit or tag is pushed“ anläuft.
Was inhaltlich gesammelt und exfiltriert wurde, zeigt die Breite eines modernen Credential-Diebstahls: Die Workflows sollten GitHub Tokens und API-Keys für mehrere Umgebungen und Services ernten, darunter die LiteLLM Deployment- und Linear-Workspace-Konfiguration sowie weitere Anbieter-Keys. Im zweiten Lauf am 12. Oktober wurde die Liste laut Analyse erweitert, unter anderem um Secrets, die für externe LLM- und Cloud-Ökosysteme wie Anthropic, OpenAI, AWS Bedrock, Tavily und GitGuardian gelten, plus Test-Umgebungsdaten wie Playwright-„storage state“. Dazu kommen Daten, die klassisch für späteres „Lateral Movement“ geeignet sind, etwa Verbindungsinformationen (Connection String), Kontodaten, Passwörter sowie Redis-Endpoint-Details. Die Daten sollten anschließend über zwei unterschiedliche webhook[.]site-Endpunkte abfließen. Als Kontext ordnet Zanki den Unterschied zwischen „Plattform-Credentials“ und „Drittanbieter-Keys“ ein: „A GitHub token and a GitHub App private key are credentials for the platform hosting the repository, not for a third-party service.“ Ebenso betont er, dass ein API-Key für Secret-Scanning-Dienste nicht nur Sichtbarkeit, sondern potenziell auch Einfluss auf Alerts liefern kann.
Die kompromittierte LiteLLM-Version 1.107.0 setzte dann auf mehrere Ausführungspfade: Die Dateien seien so gestaltet, dass beim Start von Python automatisch Code läuft, selbst wenn die betroffene Bibliothek im Zielprogramm gar nicht importiert wird. Ein Pfad übernimmt demnach das gezielte Einsammeln von Zugangsdaten über Entwickler-Tools, KI-Anwendungen, Cloud-Umgebungen und Browser, während ein Unix-orientierter Backdoor-Prozess im Hintergrund jede Stunde zusätzlichen, vom Angreifer gelieferten Code nachlädt und ausführt. Zusätzlich werden Systeminformationen, SSH-Dateien, Git-/GitLab-Zugänge, Environment Variables sowie Token für Paketmanager-Ökosysteme wie npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems und Cargo abgegriffen. Als Exfiltrationsziel wird ein HTTP POST an „litellm[.]dev/healthcheck“ genannt. Dieses Design erhöht das Risiko, weil „Entfernen des App-Verzeichnisses“ allein nicht zwingend genügt: Wenn Startup-Komponenten außerhalb des LiteLLM-Verzeichnisses platziert wurden, kann die schädliche Logik auch nach der Bereinigung weiter existieren.
Für Betreiber, die Open-Source-Projekte in CI/CD oder in produktionsnahen Workflows einsetzen, zeigt der Vorfall eine klare Konsequenz: Ein Secret-Revocation-Failed-Case ist nicht automatisch „nur ein Incident“, sondern kann mit Verzögerung zur vollständigen Kompromittierung eines Release-Systems werden. Gleichzeitig macht die Geschichte deutlich, wie wichtig die Detailhygiene in Supply-Chain-Ketten ist – von Branch-Protection über Token-Scopes bis hin zur Frage, ob Freigaben und Deployment-Auslöser an physisch gesicherte Konten oder Hardware gebunden sind. LiteLLM kündigt an, in Reaktion auf den Vorfall an der Revokation „each and every token“ zu arbeiten, die mit internen Systemen und Vendor-Plattformen verbunden sind. Für Teams bleibt damit weniger die Frage „Wie konnte das passieren?“, sondern eher „Wie beweisen wir jetzt, dass Token-Ketten tatsächlich vollständig ersetzt und keine Persistenzpfade über Startup-Komponenten übrig geblieben sind?“
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "LiteLLM-Angriff: Leak eines Master-Keys kapert Release-Pipeline und PyPI-Paket" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "LiteLLM-Angriff: Leak eines Master-Keys kapert Release-Pipeline und PyPI-Paket" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »LiteLLM-Angriff: Leak eines Master-Keys kapert Release-Pipeline und PyPI-Paket« bei Google Deutschland suchen, bei Bing oder Google News!