Docker Hub: CVE-2026-105445 ließ fremde Tokens pushen

Docker Hub konnte persönliche Zugriffstoken bei der Umwandlung eines Kontos in eine Organisation einer fremden Identität zuordnen. Dadurch waren Image-Pushes unter einem legitimen fremden Namen möglich. Docker veröffentlichte das Advisory am 12. Oktober 2026, die Forscher aktualisierten ihre Darstellung am 13. Oktober. Die serverseitige Korrektur erfolgte bereits am 30. September. Ein Docker-Engine-Update behebt diesen Vorfall deshalb nicht.

Admins sollten heute prüfen, ob die Benachrichtigung vom 2. Oktober vorliegt und welche persönlichen Zugriffstoken für Veröffentlichungen eingesetzt werden. Laut Docker waren Konten ohne diese Benachrichtigung nicht exponiert. Ein flächendeckender Austausch aller Container ist daraus nicht abzuleiten; betroffene Publisher müssen dagegen Token, Veröffentlichungen und ihre automatisierten Build-Prozesse gezielt kontrollieren.

Wie konnte ein Token die Identität wechseln?

Die als GhostPat bezeichnete Schwachstelle CVE-2026-105445 lag in der Konto-zu-Organisation-Konvertierung. Seit dem 26. August 2024 änderte dieser Ablauf den Eigentümer bestehender Personal Access Tokens, ohne deren Geheimnis zu erneuern oder zu widerrufen. Der benannte neue Eigentümer musste nicht zustimmen und erhielt keine Benachrichtigung. Ein Angreifer konnte deshalb einen eigenen Token erzeugen, sein Konto konvertieren und ein anderes vorhandenes Konto als Eigentümer angeben.

Der bekannte Token authentifizierte anschließend gegenüber der Registry als Zielkonto. Innerhalb seiner Berechtigungen waren Pull, Push und Löschen in erreichbaren Repositories möglich, auch in Organisationen des Zielnutzers. Docker stufte den Fehler wegen der möglichen Veröffentlichung manipulierter Images als kritisch ein. Das Webinterface, Passwort, E-Mail-Adresse und Zwei-Faktor-Einstellungen des Zielkontos waren laut Hersteller nicht zugänglich.

Welche Umgebungen müssen jetzt prüfen?

Der Vorfall betrifft Docker Hub und dessen Identitätsverwaltung, nicht eine konkrete Docker-Desktop- oder Engine-Version. Relevant sind insbesondere Publisher, Organisationseigentümer und CI-Pipelines mit persönlichen Tokens. Die Forscher reproduzierten den Zugriff mit zustimmenden Testkonten, einschließlich privater Repositories. Ihre Überlegung zu möglichen Auswirkungen auf offizielle Basisimages ist ausdrücklich kein bestätigter Befund und rechtfertigt keine Behauptung über kompromittierte Docker Official Images.

1. Konten mit der Docker-Mail „Docker Hub Vulnerability Identified & Resolved“ sind anhand der darin genannten Tokenbeschreibungen und Erstellungsdaten zu prüfen.
2. Organisationseigentümer sollten die separate Benachrichtigung mit den tatsächlich zuständigen Build- und Release-Verantwortlichen abgleichen.
3. Teams, die ausschließlich eine andere Registry nutzen, sind durch diesen speziellen Docker-Hub-Konvertierungsfehler nicht direkt betroffen.
4. Ein bekannt klingender Tokenname ist kein Eigentumsnachweis, weil die Beschreibung vom Ersteller frei gewählt werden konnte.

Was belegt die Untersuchung?

Docker überprüfte sämtliche Konvertierungen im Expositionszeitraum und rund 304.000 Pushes mit übertragenen Tokens. Nach Herstellerangaben ging kein solcher Push an eine unbeteiligte Organisation oder ein unbeteiligtes Konto. Die statische Untersuchung der risikoreichsten öffentlichen Images ergab keine Malware oder Manipulation. Docker fand keine Hinweise auf Ausnutzung; das ist ein Untersuchungsbefund, keine uneingeschränkte Garantie für jeden historischen Zugriff.

Die Registry protokolliert die Verwendung eines Tokens, nicht seine bloße Existenz. Deshalb behandelte Docker alle übertragenen Tokens als potenziell betroffen. Das Advisory beschreibt insbesondere Push-Prüfungen; eine gleichwertig detaillierte öffentliche Bilanz zu privaten Pulls oder Löschungen enthält es nicht. Unternehmen sollten diese Grenze bei der eigenen Bewertung möglicher Datenabflüsse berücksichtigen.

Welche Maßnahmen haben Vorrang?

1. Zuerst Benachrichtigung, Tokeninventar und frühere Kontokonvertierungen miteinander abgleichen, statt pauschal Containerhosts zu patchen.
2. Unbekannte oder ungenutzte persönliche Tokens widerrufen und benötigte CI-Zugänge kontrolliert neu ausstellen.
3. Prüfen, ob ein übertragener Token von der erzwungenen Deaktivierung am 8. Oktober ausgenommen wurde, weil sein Besitzer widersprochen hatte.
4. Push-Zeitpunkte, Tags und Image-Digests mit freigegebenen Build-Läufen vergleichen; unerklärte Veröffentlichungen intern eskalieren.
5. Bei Organisationsautomatisierung nach Möglichkeit organisationsgebundene Zugriffstoken statt persönlicher Entwicklerzugänge einsetzen.
6. Für veränderte Zugangsdaten einen kontrollierten Test-Push vorsehen und anschließend verifizieren, dass nur die vorgesehenen Repositories erreichbar sind.

Die Korrektur entfernt Tokenübertragungen aus dem Konvertierungsablauf. Zusätzlich nennt Docker Zustimmung und Benachrichtigung neuer Organisationseigentümer, eine nachvollziehbare Historie von Token-Eigentümerwechseln und die Prüfung ähnlicher Prozesse. Für kleine Teams ist die wichtigste Konsequenz eine klare Trennung zwischen persönlicher Anmeldung und organisatorischer Release-Automatisierung.

Passende Anleitungen und Quellen

Passende Anleitungen auf S-EDV

1. Docker-Images mit Trivy prüfen: ergänzt die Kontrolle von Image-Inhalten und SBOMs, beweist aber allein keine legitime Herkunft eines Pushs.
2. Harbor als eigene Container-Registry betreiben: beschreibt lokale Registry-Verwaltung und Rollenrechte für Teams mit eigener Veröffentlichungsinfrastruktur.

Quellen

1. Docker-Advisory vom 12. Oktober: Ablauf, Korrektur, Benachrichtigungen und Untersuchungsgrenzen.
2. GhostPat-Dokumentation der Entdecker, aktualisiert am 13. Oktober: technische Reproduktion und ausdrücklich begrenzte Testaussagen.
3. The Hacker News vom 13. Oktober: ergänzende Einordnung der Registry- und Tokenkontrollen.