Docker Engine 29.3.1: AuthZ-Bypass CVE-2026-34040 schließen und Update-Workflow prüfen

Docker hat am 25. März 2026 mit Version 29.3.1 eine als hoch eingestufte Sicherheitslücke in Docker Engine geschlossen. CVE-2026-34040 (CVSS 8.8) erlaubte es Angreifern mit Zugriff auf die Docker-API, Autorisierungs-Plugins (AuthZ) zu umgehen und dadurch privilegierte Container mit vollem Host-Zugriff zu starten – selbst wenn eine strikte AuthZ-Richtlinie konfiguriert war. Wer Docker produktiv betreibt und Container-API-Zugriff nicht ausschließlich lokal und vertrauenswürdig hält, sollte jetzt aktualisieren.

Was ist passiert

Die Sicherheitsfirma Cyera Research fand die Lücke und beschreibt sie so: Anfragen an die Docker-API, die größer als 1 MB sind, wurden von Docker Engine intern stillschweigend verworfen, bevor sie an installierte AuthZ-Plugins zur Prüfung weitergereicht wurden. Ein Angreifer konnte damit gezielt überdimensionierte Requests bauen, die AuthZ-Prüfungen komplett umgingen – etwa Richtlinien, die verhindern sollen, dass Container mit --privileged oder mit Host-Mount-Zugriff gestartet werden. Docker selbst bestätigte die Lücke in seinen offiziellen Release Notes zu Version 29.3.1 und verweist auf die Sicherheitsempfehlung GHSA-x744-4wpc-v9h2 im moby/moby-Repository.

Laut Docker handelt es sich um eine unvollständige Fix-Iteration einer früheren, als maximal kritisch eingestuften Schwachstelle (CVE-2024-41110) aus dem Jahr 2024. Wer damals gepatcht hatte, ist gegen CVE-2026-34040 nicht automatisch geschützt – die neue Lücke nutzt einen anderen Umgehungsweg über die Request-Größenprüfung.

Wer ist betroffen

Betroffen sind alle Docker-Engine-Installationen vor Version 29.3.1 sowie Docker Desktop vor 4.66.1, sofern AuthZ-Plugins zur Zugriffskontrolle eingesetzt werden – etwa in Multi-Tenant-Umgebungen, CI/CD-Runnern mit Docker-API-Zugriff oder Umgebungen mit Open Policy Agent (OPA) als Docker-Autorisierungsschicht. Klassische Docker-Compose-Setups ohne AuthZ-Plugin sind von dieser konkreten Lücke nicht direkt betroffen, sollten aber trotzdem aktualisieren, da 29.3.1 weitere Fixes bündelt.

Docker Engine auf Linux-Servern aktualisieren

Bevor produktive Server aktualisiert werden, lohnt sich ein kurzer Vorab-Check der laufenden Version und ein Blick auf laufende Container, die während des Updates neu gestartet werden könnten.

1. Aktuelle Version prüfen: docker version --format '{{.Server.Version}}'
2. Laufende Container dokumentieren: docker ps -a > docker-inventar-vor-update.txt
3. Paketquellen aktualisieren (Debian/Ubuntu): sudo apt-get update
4. Verfügbare Version prüfen: apt-cache policy docker-ce
5. Update einspielen: sudo apt-get install --only-upgrade docker-ce docker-ce-cli containerd.io docker-compose-plugin
6. Dienst-Neustart bestätigen: sudo systemctl status docker
7. Version nach Update verifizieren: docker version --format '{{.Server.Version}}' – sollte 29.3.1 oder neuer anzeigen
8. Container-Status nach dem Neustart mit dem Inventar von Schritt 2 abgleichen

Auf RHEL/Rocky/AlmaLinux läuft der Ablauf analog über dnf update docker-ce docker-ce-cli containerd.io docker-compose-plugin. Docker Desktop unter Windows/macOS aktualisiert sich in der Regel automatisch, sollte aber manuell über Docker Desktop → Check for Updates auf 4.66.1 oder neuer geprüft werden.

Docker Compose: Container nach dem Engine-Update aktualisieren

Das Docker-Engine-Update betrifft nur den Docker-Daemon selbst, nicht die laufenden Container-Images. Wer zusätzlich sicherstellen will, dass Container-Images auf aktuellem Patch-Stand laufen, aktualisiert im Anschluss die Compose-Stacks:

1. In das jeweilige Compose-Verzeichnis wechseln: cd /pfad/zu/compose-projekt
2. Aktuelle Images ziehen: docker compose pull
3. Container mit neuen Images neu erstellen, ohne Volumes zu zerstören: docker compose up -d
4. Nicht mehr benötigte alte Images bereinigen: docker image prune -f
5. Logs auf Startfehler prüfen: docker compose logs --tail=50

Wichtig: docker compose down gefolgt von up entfernt anonyme Volumes ohne stabilen Namen nicht automatisch, kann aber bei falscher Volume-Konfiguration zu Datenverlust führen. Für produktive Daten immer benannte Volumes oder Bind-Mounts nutzen, niemals anonyme Volumes für persistente Daten.

Risiko für KMU und Betrieb

Für kleine und mittlere Unternehmen, die Docker ohne separate AuthZ-Plugin-Schicht betreiben, ist das direkte Risiko durch CVE-2026-34040 begrenzt – die Lücke setzt Zugriff auf die Docker-API und ein installiertes AuthZ-Plugin voraus. Kritischer wird es dort, wo Docker-Hosts mehreren Teams oder externen Dienstleistern per API zugänglich gemacht werden, etwa in Shared-Hosting-Umgebungen oder CI/CD-Pipelines mit Docker-in-Docker-Zugriff. Dort kann ein Bypass der Autorisierungsschicht dazu führen, dass ein eigentlich eingeschränkter Nutzer einen Container mit vollem Host-Dateisystemzugriff startet – ein klassischer Weg zur Root-Übernahme des gesamten Servers.

Auch wenn keine AuthZ-Plugins im Einsatz sind: Docker Engine 29.3.1 bündelt zwei weitere Fixes (CVE-2026-33997, CVE-2026-33748), die auch klassische Single-Tenant-Setups betreffen können. Ein zeitnahes Update ist deshalb für praktisch jede Docker-Installation sinnvoll.

Was Admins jetzt tun sollten

1. Docker-Engine-Version auf allen Servern prüfen (docker version)
2. Bei Version kleiner 29.3.1: Update zeitnah einspielen, siehe Anleitung oben
3. Prüfen, ob AuthZ-Plugins (z. B. Open Policy Agent, Twistlock/Prisma Authz) im Einsatz sind – dort besteht akuter Handlungsbedarf
4. Docker-API-Zugriff (Port 2375/2376 oder Unix-Socket) auf notwendige Systeme und Nutzer beschränken
5. Docker Desktop auf Arbeitsplatzrechnern zentral auf 4.66.1 oder neuer prüfen
6. Compose-Stacks nach dem Engine-Update mit docker compose pull && docker compose up -d aktualisieren

Passende Anleitungen auf S-EDV

1. Docker Engine gegen Copy Fail absichern: Update und Container-Check – ähnlicher Ablauf für eine frühere Docker-Engine-CVE.
2. LocalAI: OpenAI-kompatibler KI-Server mit Docker – Praxisbeispiel für einen Docker-Compose-Stack mit regelmäßigem Update-Bedarf.

Quellen

1. Docker Engine Release Notes Version 29 (offizielle Docker-Dokumentation)
2. Cyera Research: One Megabyte to Root – Analyse der Schwachstelle
3. The Hacker News: Docker CVE-2026-34040 Lets Attackers Bypass Authorization