Docker Engine 29.8.2: Zwei Container-Sicherheitslücken, die du nicht ignorieren kannst

Docker Engine 29.8.2 Sicherheits-Release: Was geändert wurde und was zu tun ist

Docker Engine 29.8.2 ist ein Sicherheits-Release, veröffentlicht am 30.09.2026, das zwei Schwachstellen behebt, die ohne Root-Zugriff ausnutzbar sind: einen DNS-getriggerten TLS-Bypass für Registry-Pulls (CVE-2026-92543) und die Injection gefälschter Frames in verschlüsselte Swarm-Overlay-Netzwerke (CVE-2026-92542). Wenn du deinen eigenen Docker-Daemon betreibst, besonders einen, der von privaten Registries pullt, upgrade jetzt; die beiden Advisories wurden einen Tag später, am 01.10.2026, veröffentlicht. Eine Einschränkung vorab: Dieses Release hat eine bekannte Regression bei Swarm, unten beschrieben.

Keine Quellen berichten von aktiver Ausnutzung. Die Dringlichkeit ergibt sich daraus, wie leicht die Bugs erreichbar sind: Keiner erfordert privilegierten Zugriff auf dem Zielhost.

Was in Docker Engine 29.8.2 enthalten ist und warum es wichtig ist

Das Release ist in den offiziellen Release Notes dokumentiert, mit der Änderungsliste gespiegelt in der moby/moby Diskussion #53829. Es behebt drei CVEs:

Updates gebündelter Komponenten: BuildKit v0.33.1, containerd Static Binaries v2.3.6 und runc v1.5.2.

Primäre Quellen für die beiden Hauptbugs sind die Advisories GHSA-7cfq-22r6-qp73 und GHSA-6m9p-4h64-m6vh, beide veröffentlicht am 01.10.2026.

Die zwei Bugs in einem Absatz

Der erste Bug erlaubt jedem, der DNS-Antworten auf der Leitung kontrolliert, deinen Daemon dazu zu bringen, mit einer Registry zu sprechen, ohne Zertifikate zu verifizieren, was deine Registry-Zugangsdaten offenlegt und Angreifern den Weg zur Image-Substitution ebnet. Der zweite erlaubt jedem unprivilegierten Benutzer auf einem Linux-Swarm-Knoten, UDP-Pakete zu erstellen, die mit den IPsec-Parametern eines Overlays verschlüsselt und als Frames in ein verschlüsseltes Overlay-Netzwerk injiziert werden, möglicherweise auf einem anderen Knoten.

Welche CVE gilt für welches Setup

Du musst dich nicht gleich stark um alle drei kümmern. Wenn du kein Swarm betreibst, gilt CVE-2026-92542 überhaupt nicht. Wenn du nur von öffentlichen Registries über Netzwerke pullst, die du vollständig kontrollierst, ist deine Exposition gegenüber CVE-2026-92543 begrenzt, aber nicht null. Wenn du Kubernetes-Knoten mit containerd und ohne Docker Engine betreibst, behebt das Docker-Upgrade nichts für dich; du brauchst containerds Advisory für CVE-2026-53493.

CVE-2026-92543: Wie eine DNS-Antwort TLS für deine Registry-Pulls abschaltet

Laut Advisory liegt die Ursache darin, wie der Daemon entscheidet, ob ein Registry-Host als unsicher gilt.

Der Loopback-Match-Bug, Schritt für Schritt

loadInsecureRegistries() hartcodiert 127.0.0.0/8 und ::1/128 als unsichere CIDRs. Wenn der Daemon prüft, ob ein Registry-Hostname unsicher ist, löst isCIDRMatch alle Adressen des Hostnamens auf und gibt true zurück, wenn auch nur eine davon in die Liste der unsicheren CIDRs fällt. Eine DNS-Antwortmenge, die eine Loopback-IP plus eine angreiferkontrollierte IP enthält, reicht also aus, um den gesamten Hostnamen als unsicher zu klassifizieren.

Da der Transport die Verbindung zum Hostnamen erneut aufbaut, überspringt die Verbindung zur Angreiferadresse dann die Zertifikatsverifizierung und kann auf reines HTTP zurückfallen.

Offenlegung von Zugangsdaten über X-Registry-Auth

Daraus folgen zwei Konsequenzen. Erstens sendet der Daemon den X-Registry-Auth-Header bei jedem authentifizierten Pull, sodass diese Zugangsdaten auf dem Host des Angreifers landen, wo ein ungültiges Zertifikat vorliegt, und offengelegt werden. Zweitens kann ein vertrauenswürdiger Image-Tag durch ein angreiferkontrolliertes Manifest und Layer im Image-Store ersetzt werden.

Wer ist am stärksten exponiert: CI-Runner in geteilten oder Cloud-Netzwerken, Entwicklermaschinen in nicht vertrauenswürdigen Netzwerken und jeder Host, dessen Resolver oder der Pfad dorthin nicht vollständig vertrauenswürdig ist.

Warum Split-Horizon und Unternehmens-DNS eine zweite Prüfung brauchen

Split-Horizon-Setups können legitim unterschiedliche Adressmengen zurückgeben, je nachdem, woher die Abfrage kommt. Das ist normaler Betrieb, kein Angriff. Die Frage ist, ob ein Angreifer die Antworten beeinflussen kann, die dein Daemon erhält. Wenn der Resolver deines Daemons in deinem eigenen Netzwerk liegt und du ihn kontrollierst, ist dein Risiko viel niedriger als bei einem CI-Runner, der das DNS nutzt, das ihm sein Cloud-Anbieter gibt.

Was laut Advisory NICHT mitigiert:

• Entfernen von insecure-registries-Einträgen. Die Loopback-CIDRs sind hardcodiert.
• Verwendung eines vertrauenswürdigen CA-Zertifikats für die Registry. Hilft nicht, wenn der Hostname zu Loopback auflösen kann.
• Digest-Pinning. Ist nur eine Defense-in-Depth-Maßnahme gegen Image-Substitution; sie leistet nichts gegen die Offenlegung von Zugangsdaten.

CVE-2026-92542: Gefälschte Frames in verschlüsselten Swarm-Overlay-Netzwerken

GHSA-6m9p-4h64-m6vh beschreibt einen Fehler in den Firewall-Regeln des Overlay-Treibers.

Der Fehler bei der Verschlüsselungsmarkierung

Die iptables-Regeln, die VXLAN-Datagramme zur Verschlüsselung markieren, treffen sowohl auf authentische vom Kernel gesendete Datagramme als auch auf gefälschte Datagramme zu, die von Benutzerprozessen stammen. Jedes UDP-Datagramm aus dem Host-Namensraum eines Linux-Swarm-Knotens, das an den Swarm-Datenpfad-Port gesendet wird und mit einem VXLAN-Header für die VNI eines verschlüsselten Overlays beginnt, mit dem ein laufender Container verbunden ist, wird mit den IPsec-Parametern dieses Overlays verschlüsselt.

Das Ergebnis: Ein nicht privilegierter Benutzer auf einem Swarm-Knoten kann trivialerweise gefälschte Ethernet-Frames in ein verschlüsseltes Overlay-Netzwerk auf einem anderen Knoten einschleusen. Das CVSS-Profil spiegelt dies wider: Hohe Auswirkung auf Integrität und Verfügbarkeit, keine Auswirkung auf Vertraulichkeit (CVSS 4.0 6.9, AV:L/PR:L).

Betroffene Versionen sind <= 25.0.18 sowie 26.0.0 bis 29.8.1. Behoben in 29.8.2 und v25.0.19.

Der offizielle iptables-Workaround

Die Sicherheitswarnung bietet eine exakte Gegenmaßnahme, die verhindert, dass Benutzerprozesse UDP-Pakete an den Swarm-Datenpfad-Port senden:

iptables -I OUTPUT -p udp --dport "$(docker info --format '{{.Swarm.Cluster.DataPathPort}}')" -m owner --socket-exists -j DROP

Wenn du keinen Swarm betreibst, betrifft dich diese CVE nicht. Überspringe diesen Abschnitt komplett.

Prüfe deine Gefährdung vor dem Upgrade

Versions-, CIDR- und DNS-Prüfungen

Prüfe die Daemon-Version, nicht die Client-Version:

docker version --format '{{.Server.Version}}'

Die Server-Version ist entscheidend. Du brauchst 29.8.2.

Schau dir dann an, was der Daemon aktuell als unsichere Registries einstuft:

docker info --format '{{json .RegistryConfig.InsecureRegistryCIDRs}}'

Wenn die Ausgabe Loopback-Bereiche enthält, ist das erwartet (sie sind hartcodiert), bedeutet aber, dass jeder Registry-Hostname, der zu einer Loopback-Adresse auflöst, als unsicher behandelt wird. Führe für jeden Registry-Hostname, von dem du pullst, eine Momentaufnahme-Prüfung durch:

getent ahosts "$host"

Vorsicht: DNS-Antworten können sich zwischen Prüfungen ändern. Dies bestätigt nur, ob du in diesem Moment verwundbar warst, nicht ob du es immer bist.

Auditing von CI-Runnern und Docker-in-Docker

CI-Konfigurationen pinnen oft Engine-Versionen oder verwenden Docker-in-Docker-Images, und genau diese Hosts führen authentifizierte Pulls über nicht vertrauenswürdige Netzwerke aus:

grep -rnE "docker:[0-9]+\.[0-9]+|docker-version|dind" .github/ .gitlab-ci.yml

Jeder Treffer ist ein Host, den du upgraden oder aktualisieren musst.

Welche CVEs gelten für dein Setup

Übergangsmaßnahmen während der Upgrade-Planung

Registry-Hostname-Pinning und Egress-Einschränkungen

Für CVE-2026-92543 listet die Warnung zwei Gegenmaßnahmen auf: Pinne den Registry-Hostname über vertrauenswürdiges DNS oder einen hosts-file-Eintrag auf die erwartete Adresse und beschränke den ausgehenden Netzwerkzugriff des Daemons nur auf vertrauenswürdige Registry-Endpunkte. Pinnen via hosts-file ist am schnellsten umsetzbar; Egress-Filtering ist langfristig die bessere Kontrolle.

Swarm-Datenpfad-Port absichern

Für CVE-2026-92542 wende die oben genannte iptables owner-match DROP-Regel auf jedem Linux-Swarm-Knoten an.

Setze ein Enddatum für jeden Workaround

Dies sind teilweise Gegenmaßnahmen, keine Fixes. Gib jedem davon ein Enddatum in deinem Tracker und betrachte das Upgrade als einzige vollständige Behebung. Beachte erneut, was nicht funktioniert: Bearbeiten von insecure-registries (Loopback-CIDRs sind hartcodiert), Austausch gegen eine vertrauenswürdige CA oder Verlassen auf Digest-Pinning zum Schutz von Credentials. Administratoren machen diese drei Schritte weiterhin, weil sie plausibel klingen; die Warnung schließt sie explizit aus.

So upgradest du sicher auf 29.8.2

Debian/Ubuntu-Paket-Upgrade

Wenn du aus dem Docker apt-Repository installiert hast:

sudo apt-get update && sudo apt-get install --only-upgrade docker-ce docker-ce-cli containerd.io docker-buildx-plugin
sudo systemctl restart docker

Swarm-Knoten einzeln neu starten

Starte Worker-Knoten einzeln neu und bestätige, dass verschlüsselte Overlay-Services wieder laufen, bevor du den nächsten Knoten anfasst. Bei diesem Release ist das wichtiger als üblich, aus Gründen, die im Regressions-Abschnitt unten erklärt werden.

Statische Binaries und der 25.0-Zweig

Wenn du statische Binaries nutzt, hole dir die 29.8.2-Binaries und starte den Daemon neu. Im 25.0-Zweig landete der Fix in v25.0.19 laut primärer Warnung. Sekundärquellen berichten, dass der Security-Support für die 25.0-Linie angeblich am 4. Dezember 2026 endet, also plane deinen Abschied von diesem Zweig ohnehin.

BuildKit in separaten Buildern nicht vergessen

Builder, die über den docker-container-Treiber, Remote-Builder oder Kubernetes-Builder laufen, haben ihr eigenes BuildKit. Sie bleiben möglicherweise unter v0.33.1, selbst nach dem Engine-Upgrade. Verifiziere jeden Builder separat.

Post-Upgrade-Checkliste: Cache, Credentials und Verifikation

Verifiziere, dass der Patch überall gelandet ist

• Jeder Host, der aus einer privaten Registry pullt, meldet 29.8.2 von docker version --format '{{.Server.Version}}'.
• CI-Runner-Images und Docker-in-Docker-Services sind upgraded (das grep-Output von früher ist deine Arbeitsliste).
• Jeder buildx-Builder meldet BuildKit v0.33.1 oder neuer.

Vergifteten Build-Cache bereinigen

Das Upgrade stoppt neue Cache-Vergiftung, hebt aber frühere Vergiftungen nicht auf. Prune den Build-Cache nach dem Upgrade, priorisiere dabei geteilte Builder, die Fork-PR-Builds ausgeführt haben:

docker builder prune

Entscheidung über Registry-Credential-Rotation

GHSA-7cfq-22r6-qp73 listet Credential-Leakage via X-Registry-Auth als mögliche Auswirkung. Credentials, die von einem verwundbaren Daemon beim Pull aus einer privaten Registry genutzt wurden, sollten als potenziell offengelegt betrachtet werden. Keine Quelle erzwingt Rotation, also liegt die Entscheidung bei dir basierend auf der Exposure-Historie: Wenn dein Daemon in Netzwerken gepullt hat, deren DNS du nicht voll vertrauen konntest, ist Rotation die sicherere Standardentscheidung. Prüfe ~/.docker/config.json auf deinen Runner-Hosts, um zu sehen, welche Registries gespeicherte Credentials haben.

Nur-containerd-Hosts

Prüfe Hosts, die containerd ohne Docker betreiben, gegen die eigene Warnung von containerd für CVE-2026-53493.

Und schließe den Kreis bei den Workarounds: Jeder angewandte Workaround bekommt ein Enddatum oder wird entfernt.

Eine Regression im Blick: Der 29.8.2 Overlay Join/Leave-Bug

Ein Wort zur Vorsicht, bevor du Swarm-Knoten massenhaft neu startest. Dieser Abschnitt basiert auf einem Community-Post-Mortem und Upstream-Tracking, nicht auf offiziellen Warnungen.

Symptome und Ursache

Das Problem wird upstream als moby/moby#53834 verfolgt und ist in einem Community-Post-Mortem dokumentiert. Wenn der Start eines Containers fehlschlägt, nachdem der Overlay-Treiber Join ausgeführt hat, wird ein doppeltes Leave ausgelöst, das die Endpunktanzahl pro Knoten dekrementiert. Nach N+1 solchen Fehlern wird die Overlay-Sandbox für gesunde Container auf diesem Knoten zerstört, während docker ps sie weiterhin als laufend meldet. Bis zum 03.10.2026 war kein Fix veröffentlicht.

Die Workaround-Sequenz

Laut Feldbericht: Behebe zuerst den fehlgeschlagenen Start (ein Port-Konflikt ist via docker service ps --no-trunc sichtbar), skaliere den fehlerhaften Service auf null, führe dann systemctl restart docker aus und starte die Container ohne Restart-Policy neu.

Die praktische Erkenntnis deckt sich mit der bereits beschriebenen Upgrade-Prozedur: Starte nicht alle Swarm-Knoten gleichzeitig neu. Das Neustarten eines Knotens nach dem anderen begrenzt den Blast Radius dieser Regression genauso wie beim CVE-Fix.

Was wir zuerst tun würden

Wenn du Docker auf selbst verwalteten Servern betreibst, ist die sinnvolle Reihenfolge: Prüfe docker version --format '{{.Server.Version}}' auf jedem Host, wende die iptables-Regel auf Swarm-Knoten an und pinne Registry-Hostnames auf CI-Runnern heute noch, upgrade diese Woche knotenweise auf 29.8.2, prune Build-Caches und entscheide dann über Credential-Rotation. Die Advisory-Workarounds kaufen dir Tage, keine Monate. Das Upgrade ist der Fix.

Ein Hinweis zur weiteren Lektüre: Keine unserer bisherigen Blogartikel behandelt Docker-Engine-Sicherheitsupdates detailliert genug, um hier verlinkt zu werden. Die oben genannten Sicherheitswarnungen und Release Notes sind daher die besten Referenzen.

Häufig gestellte Fragen

Behebt Docker Engine 29.8.2 die Probleme auf Kubernetes-Clustern?

Die meisten Kubernetes-Knoten laufen mit containerd ohne Docker Engine. Ein Docker-Upgrade bringt ihnen bei CVE-2026-53493 nichts, dessen Advisory im containerd-Repository liegt – prüfe stattdessen die behobenen Versionen von containerd. CVE-2026-92542 betrifft nur Swarm.

Muss ich nach dem Patching die Registry-Zugangsdaten rotieren?

Die Offenlegung von Zugangsdaten über X-Registry-Auth ist eine mögliche Auswirkung von CVE-2026-92543. Daher sollten Zugangsdaten, die ein verwundbarer Daemon beim Pullen von einer privaten Registry verwendet hat, als potenziell kompromittiert betrachtet werden. Keine Quelle verlangt eine Rotation; triff die Entscheidung basierend darauf, ob dein Daemon über Netzwerke gepullt hat, deren DNS du nicht vollständig vertrauen konntest.

Ist mein Build-Cache nach dem Upgrade sicher?

Nein. Das Upgrade stoppt neue Cache-Vergiftungen, hebt aber frühere Vergiftungen nicht auf. Bereinige den Build-Cache, priorisiere dabei gemeinsame Builder, die Fork-PR-Builds ausgeführt haben, und stelle sicher, dass jeder Builder BuildKit v0.33.1 oder neuer meldet.

Gibt es aktive Ausnutzung dieser Docker-Schwachstellen?

Keine Quellen berichten von aktiver Ausnutzung in freier Wildbahn. CVE-2026-92543 hat keinen EPSS-Score und ist nicht im KEV-Katalog der CISA enthalten, was bedeutet, dass die Wahrscheinlichkeit unbekannt ist, nicht niedrig. Die Dringlichkeit ergibt sich aus Exploits, die keinen privilegierten Zugriff benötigen.

Was passiert, wenn ich Docker Swarm nicht betreibe?

CVE-2026-92542 trifft nicht zu. Deine Exposition besteht aus CVE-2026-92543 (Registry-Pulls über DNS, den du nicht kontrollierst) und, auf Hosts, auf denen nur containerd läuft, aus CVE-2026-53493 gemäß containerds eigenem Advisory.