GhostPat – Docker-Hub-Schwachstelle, mit der sich fremde Container-Images durch Weitergabe von Personal Access Tokens steuern ließen

Docker hat die kritische Schwachstelle CVE-2026-105445 in Docker Hub behoben, die über mehr als zwei Jahre – vom 26. August 2024 bis zum 30. September 2026 – einem Angreifer erlaubte, einen von ihm kontrollierten Personal Access Token (PAT) mit dem Account eines anderen Benutzers zu verknüpfen und in dessen Namen Operationen mit Container-Images durchzuführen. Die Schwachstelle wurde mit 9,4 Punkten nach CVSS 4.0 bewertet und als kritisch eingestuft. Der Patch wurde auf der Serverseite von Docker Hub eingespielt, Client-Updates sind nicht erforderlich. Nach Angaben von Docker wurden keine Anzeichen für eine Ausnutzung der Schwachstelle in realen Angriffen gefunden; diese Einschätzung basiert jedoch ausschließlich auf der internen Untersuchung des Herstellers und ist nicht durch ein unabhängiges Audit bestätigt.

Mechanismus der Schwachstelle

Das Problem, klassifiziert als CWE-266 (fehlerhafte Zuweisung von Berechtigungen), betraf den Mechanismus zur Umwandlung eines persönlichen Docker-Hub-Accounts in einen Organisationsaccount. Laut dem CVE-Eintrag übertrug das System bei der Konvertierung alle Personal Access Tokens (PAT) automatisch auf den festgelegten Owner der Organisation. Der entscheidende Fehler: Das Secret des Tokens wurde dabei nicht geändert, und die Zustimmung des neuen Owners wurde nicht eingeholt.

Das Angriffsszenario sah wie folgt aus:

1. Der Angreifer erstellt einen Account und generiert einen PAT mit den benötigten Berechtigungen.
2. Er konvertiert seinen Account in eine Organisation und gibt das Opfer als Owner an.
3. Docker Hub verknüpft den Token mit dem Account des Opfers, wobei das Secret des Tokens unverändert bleibt.
4. Der Angreifer verwendet seinen PAT für den Zugriff auf das Registry – das System authentifiziert ihn als das Opfer.

Je nach Berechtigungen des Tokens und den Rechten des Opfers konnte der Angreifer Container-Images in den Repositories des Opfers herunterladen, hochladen und löschen – einschließlich der Repositories von Organisationen, auf die das Opfer Zugriff hatte. Der Zugriff war auf Registry-Operationen beschränkt: Das Web-Interface von Docker Hub, das Ändern von Passwort, E-Mail-Adresse oder Einstellungen für die Zwei-Faktor-Authentifizierung blieben nicht erreichbar.

Warum die Einstufung als kritisch

Trotz des begrenzten Angriffsperimeters stufte Docker die Schwachstelle als kritisch ein, da sie eine Bedrohung für die Software-Lieferkette darstellt: Ein Angreifer konnte bösartige Images im Namen legitimer Entwickler veröffentlichen. Zum Kontext: Bereits Anfang 2026 berichtete Docker über Fälle, in denen gestohlene Zugangsdaten von Publishern genutzt wurden, um bösartige Trivy- und KICS-Images in deren eigene Repositories hochzuladen. GhostPat eröffnete einen alternativen Angriffsvektor für ähnliche Attacken – ohne dass Passwörter gestohlen werden mussten.

Bemerkenswert: Die eigene Docker-Dokumentation beschrieb ab April 2025 die Übertragung von PATs bei der Konvertierung eines Accounts ausdrücklich als erwartetes Standardverhalten. Dieser Hinweis wurde am 30. September 2026 entfernt – nur wenige Minuten nach dem Ausrollen des Patches. Damit war das verwundbare Verhalten während rund 17 von 25 Monaten seines Bestehens als Funktion und nicht als Fehler dokumentiert.

Untersuchung und Reaktion

Die Schwachstelle wurde von den Forschern Péter Molnár und Christian Hozák (mptrdev.com) entdeckt, die ihr den Namen GhostPat gaben. Laut The Hacker News reproduzierten sie den Exploit mit Zustimmung der Besitzer zweimal auf Testaccounts und bestätigten so die Möglichkeit, sich im Registry im Namen des Zielbenutzers anzumelden, Repositories in dessen Namensraum zu erstellen und auf private Repositories zuzugreifen. Docker rollte den Patch nach eigenen Angaben in weniger als vier Stunden nach Eingang des Berichts aus.

Nach Aussage von Docker überprüfte das Unternehmen alle Account-Konvertierungen während der Lebensdauer des Bugs und analysierte rund 304.000 Image-Upload-Operationen, die mit übertragenen Tokens durchgeführt wurden. All diese Uploads seien laut Hersteller in Repositories der konvertierten Organisation oder ihres festgelegten Owners erfolgt, wobei in der überwiegenden Mehrzahl der Fälle beide Accounts derselben Person oder demselben Team gehörten. Für Fälle, in denen sich dies nicht bestätigen ließ, analysierte Docker öffentliche Images mit erhöhtem Risiko und fand keinen bösartigen Code. Zu berücksichtigen ist, dass diese Daten keiner unabhängigen Verifizierung unterzogen wurden und der Docker-Bericht keine Ergebnisse zur Überprüfung von Download- und Löschoperationen von Images offenlegt.

Praktische Empfehlungen

Am 2. Oktober 2026 informierte Docker die Nutzer, deren Accounts mit fremden Tokens verknüpft waren, sowie die Owner betroffener Organisationen. Am 8. Oktober wurden potenziell gefährliche Tokens deaktiviert (mit Ausnahme derjenigen, deren Owner ausdrücklich um deren Beibehaltung gebeten hatten). Nutzern, die keine Benachrichtigung erhalten haben, sind laut Docker keine Maßnahmen erforderlich.

Für alle, die eine Benachrichtigung erhalten haben oder selbst eine Überprüfung durchführen möchten:

• Öffnen Sie die Accounteinstellungen → Personal access tokens. Prüfen Sie das Erstellungsdatum und die letzte Verwendung jedes Tokens.
• Widerrufen Sie Tokens, die Sie nicht selbst erstellt haben oder nicht mehr verwenden. Die Beschreibung eines Tokens wird vom Ersteller festgelegt, daher garantiert ein vertrauter Name keine Legitimität.
• Prüfen Sie die Liste der Organisationen im Account-Switcher – eine unbekannte Organisation kann ein Hinweis auf eine Konvertierung sein.
• Für automatisierte Prozesse auf Organisationsebene sollten Sie statt persönlicher PATs Organization Access Tokens verwenden (erfordert ein Docker-Team- oder Docker-Business-Abonnement).
• Owner von Organisationen mit kostenpflichtigen Abonnements können die Upload-Historie über die Activity Logs prüfen (werden 30 Tage in der Oberfläche aufbewahrt, ältere Einträge sind über die API verfügbar).
• Wenn Sie Images signieren, prüfen Sie die Signaturen der veröffentlichten Images und gleichen Sie sie mit den Einträgen Ihrer CI/CD-Pipeline ab.

Docker gibt an, dass das System nun die ausdrückliche Zustimmung eines Benutzers verlangt, bevor er als Owner einer Organisation festgelegt wird, über eine solche Zuweisung informiert und alle Änderungen an den Token-Ownern protokolliert. Die wichtigste Maßnahme für Nutzer von Docker Hub ist ein Audit ihrer PATs und der Wechsel zu Organization Tokens für jede Automatisierung, die mit Organisationen verbunden ist. Für Konsumenten öffentlicher Images unterstreicht der Vorfall den Wert der Verifizierung von Image-Signaturen: Gerade die Signatur – nicht der Name des Publishers – bleibt ein verlässlicher Indikator für Integrität im Ökosystem der Container-Registries.