Alter Docker-Build gab Admin-Zugriff auf Baseten-Repositories frei
16. September 2026
Ein öffentlicher Container enthielt einen mehr als drei Jahre alten GitHub-Token mit weitreichenden Rechten. Der Fund zeigt, warum gelöschte Dateien allein keine Build-Secrets beseitigen.
Worum es geht
Die Sicherheitsfirma Strix hat bei einer Prüfung des KI-Inferenzanbieters Baseten einen aktiven GitHub-Token in einem öffentlich abrufbaren Container-Image gefunden. Nach Angaben von Strix führte der Token zu Admin- und Push-Rechten auf interne Repositories, darunter Produktcode, GitOps-Konfiguration und ein Homebrew-Repository. Strix meldete den Fund am 13. Juli 2026; Baseten schützte das Registry-Projekt und rotierte den Token am folgenden Tag. Die technische Offenlegung erschien am 16. September 2026.
Der Fall ist relevant, weil kein neuartiger Exploit nötig war. Ein altes Build-Artefakt verband eine öffentliche Registry mit einem langlebigen Zugangsschlüssel. Wer Container baut oder KI-Dienste einkauft, muss deshalb nicht nur laufende Systeme, sondern auch alte Images und deren Metadaten prüfen.
Was der Tokenfund tatsächlich zeigt
Strix begann laut eigener Darstellung mit einer nicht authentifizierten Prüfung der Baseten-Domains. Der Agent fand eine Harbor-Registry mit einem öffentlichen Projekt, lud ein Image und untersuchte dessen Ebenen sowie Build-Historie. Ein zunächst gefundener AWS-Schlüssel war ungültig. In history[].created_by lag jedoch ein GitHub Personal Access Token, den GitHub noch dem Konto basetenbot zuordnete.
Der Build-Schritt stammte vom 3. März 2023. Der Token funktionierte bei der Prüfung im Juli 2026 weiterhin und besaß laut den von Strix veröffentlichten, redigierten Antworten den OAuth-Scope repo. Strix erklärt, nur lesende Abfragen vorgenommen und weder Repositories geklont noch Änderungen übertragen zu haben. Baseten bestätigte den Fund nach Darstellung der Forscher als kritisch. Eine eigene öffentliche technische Stellungnahme von Baseten liegt in den geprüften Quellen nicht vor.
Warum das wichtig ist
Docker weist ausdrücklich darauf hin, dass Build-Argumente und Umgebungsvariablen ungeeignet sind, um Geheimnisse in Builds zu übergeben: Werte können in Image-Metadaten oder der Historie erhalten bleiben. Selbst wenn eine Datei in einer späteren Ebene gelöscht wird, können ältere Ebenen oder Konfigurationsdaten den Wert weiter enthalten. Empfohlen werden kurzlebige, eng begrenzte Zugangsdaten und BuildKit-Secret-Mounts.
Der Schaden wäre bei Missbrauch nicht auf Quellcode-Lesen beschränkt gewesen. Push- und Admin-Rechte auf Produkt- und Deployment-Repositories können eine Lieferkette treffen: veränderte Releases, manipulierte Infrastrukturkonfigurationen oder kompromittierte Update-Kanäle wären grundsätzlich denkbar. Dass Strix den Token nach eigenen Angaben innerhalb von rund 25 Minuten fand, ist keine unabhängige Leistungsprüfung des Produkts, macht aber die geringe Hürde des konkreten Fehlers sichtbar.
Einfach erklärt
Ein Container-Image ist wie ein Umzugskarton mit mehreren transparenten Lagen. Wer oben einen Schlüssel entfernt, hat ihn nicht automatisch aus einer unteren Lage genommen. Wird der ganze Karton öffentlich ins Lager gestellt, kann jemand jede Lage prüfen und den alten Schlüssel finden.
Praktisches Beispiel
Ein Team baut täglich 20 Container und übergibt einem Build einmal einen GitHub-Token. Drei Jahre später sind 5.000 Tags vorhanden, obwohl nur 50 aktiv genutzt werden. Ein Scanner prüft nicht nur Dateien, sondern auch die vollständige Build-Historie aller erreichbaren Images. Findet er einen Token, muss das Team ihn sofort sperren, die Reichweite über Audit-Logs prüfen, betroffene Images neu bauen und alte Artefakte aus der Registry entfernen. Nur den aktuellen Dockerfile-Eintrag zu ändern, beendet den Zugriff des bereits kopierten Tokens nicht.
Einordnung und Grenzen
- Die detaillierten Berechtigungen und der Ablauf stammen überwiegend von Strix; öffentlich zugängliche Belege sind redigiert, damit keine Zugangsdaten offengelegt werden.
- Es gibt in den geprüften Quellen keinen Beleg, dass Unbefugte den Token vor Strix missbraucht oder Kundendaten abgerufen haben. Ein potenzieller Zugriff ist kein bestätigter Datenabfluss.
- Ein automatischer Scanner ersetzt weder Berechtigungsdesign noch Incident Response. Er kann Funde übersehen, Fehlalarme erzeugen oder ohne klare Grenzen selbst Risiken verursachen.
SEO- und GEO-Schlüsselbegriffe
Baseten, Strix, GitHub Token, Docker Build Secrets, Harbor Registry, Container-Sicherheit, Software Supply Chain, BuildKit Secret Mount, GitOps, Repository-Zugriff
💡 Im Klartext
Ein öffentlicher Container enthielt einen noch gültigen GitHub-Schlüssel mit sehr weitreichenden Rechten. Baseten sperrte den Zugang nach der Meldung; es gibt keinen bestätigten Hinweis auf einen vorherigen Datenabfluss.
Wichtigste Erkenntnisse
- →Der Token stammte aus einem Build vom März 2023 und funktionierte im Juli 2026 noch.
- →Er lag laut Strix in der Docker-Build-Historie und nicht nur in einer sichtbaren Datei.
- →Die gemeldeten Rechte umfassten Admin- und Push-Zugriff auf interne Repositories.
- →Baseten schützte das Registry-Projekt und rotierte den Token nach der Meldung.
- →BuildKit-Secret-Mounts und kurzlebige, begrenzte Tokens reduzieren dieses Risiko.
Häufige Fragen
Wurde bei Baseten ein Datenabfluss bestätigt?
Nein. Die geprüften Quellen belegen einen erreichbaren Token mit weitreichenden Rechten, aber keinen Missbrauch durch Unbefugte oder bestätigten Abfluss von Kundendaten.
Warum blieb der Token im Container sichtbar?
Der Wert wurde in einem Build-Schritt verwendet und laut Strix in der Image-Historie gespeichert. Späteres Löschen einer Datei entfernt solche Metadaten nicht automatisch.
Was sollten Teams jetzt prüfen?
Öffentlich erreichbare Registry-Projekte, alte Images, Build-Historien, Token-Laufzeiten und tatsächliche Repository-Rechte sollten geprüft werden.