Docker Hub-Flaw ließ Tokens als andere Benutzer handeln
Ein Docker Hub-Flaw erlaubte es personal access tokens, bei der container registry als anderer Benutzer zu handeln, wodurch der Token-Inhaber die Möglichkeit hatte, innerhalb der Berechtigungen des betroffenen Kontos images zu pushen, zu pullen oder zu löschen. Docker behob das Problem am 30. September und erklärte, keine Hinweise darauf gefunden zu haben, dass die vulnerability ausgenutzt wurde.
Docker Hub ist die registry, die zum Veröffentlichen und Herunterladen von container images verwendet wird, also gepackten Softwarekomponenten, die häufig von Entwicklungsteams, Hosting-Anbietern und Cloud-Diensten genutzt werden. Docker erklärte, das Problem habe in dem Prozess gelegen, der ein persönliches Konto in eine Organisation umwandelt. Während dieser Umwandlung wurden personal access tokens, oft zu PATs abgekürzt, auf das Konto übertragen, das als neuer Organisationseigentümer benannt wurde. Ein PAT ist ein Geheimnis, das anstelle eines Passworts verwendet wird, wenn Software eine Verbindung zur registry herstellt, und Docker sagte, die Person, die den jeweiligen Token ursprünglich erstellt hatte, habe ihn weiterhin verwenden können.
Das Problem war auf registry-Zugriff beschränkt. Docker sagte, es habe keinen Zugriff auf die Docker Hub-Weboberfläche ermöglicht und könne nicht verwendet werden, um ein Kontopasswort, eine E-Mail-Adresse oder two-factor authentication-Einstellungen zu ändern. Es konnte auch nicht verwendet werden, um über diese Webeinstellungen ein Konto zu übernehmen. Die Auswirkung war dennoch schwerwiegend, weil ein übertragener Token je nach Berechtigungsstufe des Tokens bei der registry als benannter Eigentümer funktionieren konnte.
Docker verfolgt die vulnerability als CVE-2026-105445 und stufte sie als kritisch ein. Der am 13. Oktober veröffentlichte CVE-Eintrag weist ihr einen CVSS 4.0-Score von 9.4 zu. Docker sagte, der Flaw habe vom 26. August 2024 bis zur Behebung bestanden, also etwas mehr als zwei Jahre. Die Behebung wurde direkt auf Docker Hub angewendet, sodass Benutzer kein Softwareupdate installieren müssen, um die plattformseitige Korrektur zu erhalten.
Die Mechanik ist für jedes Team wichtig, das sich in Build- oder Deployment-Pipelines auf container images verlässt. Docker Hub verschiebt kein Repository von einem Konto zu einem anderen. Stattdessen kann ein Benutzer ein persönliches Konto in eine Organisation umwandeln, die denselben Namen behält, während ein bestehendes Konto als Eigentümer benannt wird. Während der Flaw vorhanden war, änderte diese Umwandlung den verzeichneten Eigentümer jedes PAT, ließ das Geheimnis aber unverändert. Praktisch ausgedrückt konnte ein von einer Person erstellter Token von der registry akzeptiert werden, als gehöre er dem neu benannten Eigentümer.
Docker und die Forscher, die den Flaw meldeten, sagten, der benannte Eigentümer sei nicht aufgefordert worden, die Änderung zu genehmigen, und sei nicht benachrichtigt worden. Die Umwandlungsseite von Docker enthielt seit mindestens August 2024 eine Formulierung, wonach der neue Eigentümer eine Benachrichtigungs-E-Mail erhält. Die Forscher von mptrdev.com nannten das Problem GhostPat und erklärten in ihrem technischen Bericht, sie hätten es zweimal mit einwilligenden Testkonten reproduziert. Sie sagten, sie hätten sich bei der registry als Zielkonto anmelden, ein Repository in diesem namespace erstellen und dorthin pushen, zu einer Organisation pushen, der das Ziel angehörte, und private Repositories pullen können.
Die möglichen Aktionen hingen von den Berechtigungen des übertragenen Tokens ab. Innerhalb dieser Grenzen konnte er images pullen, images pushen oder images in Repositories löschen, die dem benannten Benutzer gehörten, sowie in Organisationen, auf die dieser Benutzer Zugriff hatte. Docker sagte, es habe den Flaw als kritisch eingestuft, weil der Zugriff das Veröffentlichen von images unter einem legitimen Namen einschließen konnte. Dieses Risiko ist für Website- und Infrastrukturteams bedeutsam, weil container images häufig automatisierte Deployment-Systeme speisen und ein vertrauenswürdiger Repository-Name betriebliches Gewicht haben kann.
Docker verwies außerdem auf separate Vorfälle im März und April, bei denen Angreifer gestohlene Publisher-Zugangsdaten nutzten, um bösartige Trivy-images und bösartige KICS-images in die eigenen Docker Hub-Repositories der Publisher zu pushen. Diese Vorfälle werden nicht als Ausnutzung dieser vulnerability beschrieben, zeigen aber, warum registry-Zugangsdaten und vertrauenswürdige image-Namen sensible Sicherheitswerte sind.
Docker sagte, es habe jede Kontoumwandlung überprüft, die während des betroffenen Zeitraums vorgenommen wurde, und die Umwandlungen mit registry-Logs und Token-Datensätzen verglichen. Das Unternehmen suchte nach Tokens, die unter mehr als einer Identität verwendet wurden, und untersuchte jeden Push, der mit einem übertragenen Token durchgeführt wurde, insgesamt etwa 304.000 Pushes. Docker sagte, es habe keine Hinweise darauf gefunden, dass die vulnerability ausgenutzt worden sei.
Laut Docker ging jeder überprüfte Push an ein Repository, das entweder der umgewandelten Organisation oder ihrem benannten Eigentümer gehörte. In den meisten Fällen sagte Docker, beide Konten schienen derselben Person oder demselben Team zu gehören. Wo Docker nicht bestätigen konnte, dass eine Person beide Konten kontrollierte, analysierte es die öffentlichen images mit dem höchsten Risiko, ohne sie auszuführen, und sagte, es habe keine malware oder tampering gefunden.
Diese Überprüfung hat eine wichtige Grenze. Docker sagte, registry-Logs zeigen, wann ein Token verwendet wird, nicht nur, dass er existiert. Ein übertragener Token, der nie verwendet wurde, würde in diesen Logs nicht erscheinen. Aus diesem Grund behandelte Docker jeden Token, der durch eine Umwandlung während des betroffenen Zeitraums übertragen wurde, als potenziell betroffen, unabhängig davon, ob er verwendet worden war oder nicht. Dockers Advisory berichtet die Ergebnisse für Pushes, gibt aber nicht an, was das Unternehmen bei Pulls oder Löschungen fand, die mit übertragenen Tokens vorgenommen wurden, einschließlich Pulls aus privaten Repositories.
Am 2. Oktober schickte Docker E-Mails an Benutzer, deren Konten übertragene Tokens erhalten hatten, und separat an die Eigentümer der beteiligten Organisationen. Die E-Mails führten die relevanten Tokens nach Beschreibung und Erstellungsdatum auf. Docker gab nicht an, wie viele Benutzer oder Tokens enthalten waren, und beschrieb die betroffene Gruppe nur als eine begrenzte Anzahl von Benutzern. Docker sagte, wer die E-Mail nicht erhalten habe, sei nicht betroffen und müsse nichts tun.
Docker deaktivierte die identifizierten übertragenen Tokens am 8. Oktober. Tokens, deren Eigentümer darum gebeten hatten, sie zu behalten, wurden nicht deaktiviert. Ein Publisher des Docker Compose-Linters compose-lint schrieb, er habe am 2. Oktober zwei E-Mails erhalten, eine als Organisationseigentümer und eine für sein Benutzerkonto. Er sagte, er habe zwei continuous integration-Tokens rotiert und Signaturen auf 42 veröffentlichten images geprüft, wobei er jedes image bis zu dem Build-Lauf zurückverfolgte, der es erstellt hatte.
Docker rät Benutzern, ihre personal access tokens zu überprüfen, alle zu widerrufen, die sie nicht erkennen oder nicht mehr verwenden, und organization access tokens für Automatisierung zu nutzen, die zu einer Organisation gehört, statt das PAT einer einzelnen Person zu verwenden. In Docker Hub können Benutzer Account settings und dann Personal access tokens öffnen, um zu sehen, wann jeder Token erstellt und wann er zuletzt verwendet wurde. Die Forscher schlugen außerdem vor, auf einen Token zu achten, den der Benutzer nicht erstellt hat, unabhängig von dessen Beschreibung, sowie auf eine unbekannte Organisation, die im account switcher erscheint.
Organization access tokens erfordern ein Docker Team- oder Docker Business-Abonnement. Docker sagt, sie würden von einem Organisationseigentümer, einem Unternehmenseigentümer oder einer custom role mit dieser Berechtigung verwaltet und funktionierten nicht mit Docker Desktop oder Image Access Management.