Wer gehandelt hat und wer genannt wird: Zwei Plattform-Korrekturen schließen dieselbe Lücke

Victoria Shinder13 October 2026, 06:542 Min. Lesezeit

Zwei Ankündigungen der vergangenen Tage – Dockers Sicherheitshinweis zu CVE-2026-105445 und GitHubs Vorschau der Push-Zuordnung –, wirken unverbunden. Das eine ist eine Schwachstelle, das andere eine Funktion. Beide behandeln aber dieselbe Lücke: einen Eintrag, der eine Identität nennt, während eine andere die Arbeit getan hat.

Docker Hub: Der Eintrag wanderte, das Geheimnis nicht. Beim Umwandeln eines Docker-Hub-Kontos in eine Organisation wurden dessen Personal Access Tokens dem benannten Eigentümer zugewiesen, indem nur der Besitzereintrag geändert wurde. Das Geheimnis wurde nicht rotiert. Wer das Token erzeugt hatte, behielt es – und es meldete sich fortan als jemand anderes an. Docker fand bei rund 304.000 Pushes keine Ausnutzung, sagte aber auch klar, dass Logs zeigen, wann ein Token benutzt wird, nicht dass es existiert – deshalb galt jedes übertragene Token als betroffen und wurde am 8. Oktober deaktiviert.

GitHub: Der Eintrag enthielt den Handelnden nie. Autor und Committer eines Commits sind Zeichenketten, die der Client schreibt; GitHubs eigener Changelog sagt, dass jeder mit Schreibrechten sie beliebig setzen kann. Die Identität, die GitHub beim Push tatsächlich authentifiziert, wurde bisher nicht mit jedem Commit gespeichert. Die Push-Zuordnung fügt sie hinzu, und eine neue Regel weist Pushes ab, deren Committer-Adresse keine verifizierte Adresse des Pushers ist.

Die gemeinsame Lehre. In beiden Fällen liest ein Audit, das den sichtbaren Eintrag liest – Besitzer des Tokens, Committer des Commits –, eine Behauptung. Der authentifizierte Handelnde ist eine eigene Tatsache, und bisher lag sie entweder anderswo (Registry-Logs, Push-Logs) oder gar nicht vor.

Was daraus praktisch folgt.

• Zugangsdaten bevorzugen, die der Organisation gehören. Docker rät selbst zu Organization Access Tokens für Automatisierung statt persönlicher PATs; dieselbe Überlegung gilt für jede Registry oder Code-Plattform, auf der ein persönliches Token einen Rollenwechsel überdauert.
• Besitzwechsel als Ereignis für Zugangsdaten behandeln. Eine Übertragung, Umwandlung oder Rollenänderung, die ein Geheimnis am Leben lässt, ist der Moment, es zu rotieren. Docker führt genau deshalb eine Zustimmung und eine prüfbare Historie der Token-Besitzwechsel ein.
• Den Handelnden neben dem Artefakt speichern. Bietet eine Plattform ein authentifiziertes „wer hat das getan“-Feld – GitHubs Pusher-Identität ist das jüngste Beispiel –, sollte man es einschalten und in Audit-Abfragen nutzen, denn eine spätere Rekonstruktion aus Logs hängt an Logs, die es vielleicht nicht gibt.

Keine der beiden Änderungen löst das Problem der anderen. Zusammen zeigen sie die Richtung: Vertrauen in der Lieferkette wandert von dem, was ein Eintrag sagt, zu dem, wer beim Schreiben authentifiziert war.

Quellen: Docker, Hinweis zu CVE-2026-105445 — https://www.docker.com/blog/docker-hub-security-advisory-cve-2026-105445 ; GitHub Changelog, Push-Zuordnung — https://github.blog/changelog/2026-10-12-push-attribution-public-preview