Docker sicher aktualisieren: Schritt-für-Schritt-Anleitung nach der CopyEscape-Lücke CVE-2026-17106

Anfang August 2026 hat der Sicherheitsdienstleister Imperva mit CVE-2026-17106 (Spitzname "CopyEscape") eine Schwachstelle im docker cp-Befehl offengelegt, die zeigt, wie schnell ein alltäglicher Docker-Befehl zur Host-Kompromittierung werden kann. Ein bösartiger Container kann die Archiv-Erstellung beim Kopieren von Dateien so manipulieren, dass die Docker-CLI auf dem Host Dateien außerhalb des eigentlichen Zielverzeichnisses erstellt oder überschreibt, etwa Shell-Startup- Skripte, SSH-Konfigurationen oder sogar die runc-Binary selbst. Der Fall ist ein guter Anlass, die eigene Docker-Update-Routine grundsätzlich zu überprüfen: Wer nicht regelmäßig aktualisiert, fährt Monate mit bekannten, bereits gepatchten Lücken weiter.

Worum es bei CopyEscape geht

docker cp kopiert scheinbar einfach Dateien zwischen Container und Host. Tatsächlich liest der Docker-Daemon dafür das Container-Dateisystem, packt die gewünschten Dateien in ein Tar-Archiv und die Docker-CLI extrahiert dieses Archiv anschließend auf dem Host. Genau an dieser Schnittstelle entsteht das Problem: Ein manipulierter Container kann ein inkonsistentes Archiv erzeugen und einen symbolischen Link einschleusen, dem die CLI beim Extrahieren folgt, statt ihn auf das Zielverzeichnis zu beschränken. Das Ergebnis ist ein Schreibprimitive mit den Rechten des Nutzers, der docker cp ausführt. Besonders relevant ist das für CI-Systeme, Entwickler-Workstations und Incident-Response-Workflows, wo docker cp routinemäßig genutzt wird, um Artefakte, Logs oder forensische Beweise aus Containern zu ziehen. Das bedeutet: Allein das Herausziehen von Beweismaterial aus einem kompromittierten Container kann den Angriff auslösen.

Gepatcht wurde die Lücke mit Docker Engine 29.7.0 durch ein Update der Bibliothek github.com/moby/go-archive auf Version 0.3.0. Wer eine ältere Engine-Version fährt, ist weiterhin verwundbar.

Warum regelmäßige Docker-Updates Pflicht sind

CopyEscape ist kein Einzelfall. Allein im Docker-Engine-29-Zweig wurden 2026 mehrere sicherheitsrelevante Lücken in der Copy- und Archiv-Funktionalität geschlossen, darunter TOCTOU-Probleme (Time-of-Check-to- Time-of-Use) beim Kopieren von und in Container. Der Grund liegt in der Architektur von Docker selbst: Container-Dateisysteme werden von Natur aus als potenziell nicht vertrauenswürdig behandelt, wenn Daten daraus auf den Host übertragen werden. Neue Angriffsklassen in diesem Bereich werden absehbar weiterhin gefunden. Ohne feste Update-Routine sammeln sich ungepatchte, öffentlich bekannte Schwachstellen im eigenen Betrieb an.

Vor dem Update: Vorbereitung

Docker Engine unter Ubuntu/Debian aktualisieren

Für produktive Server mit Ubuntu oder Debian und Docker aus dem offiziellen Docker-Repository läuft das Update über den regulären Paketmanager:

sudo apt-get update
apt list --upgradable | grep docker
sudo apt-get install --only-upgrade docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
docker version

Nach dem Update sollte die Server-Version mindestens 29.7.0 sein, besser die zum Zeitpunkt des Updates aktuellste Version aus dem 29er-Zweig. Der Docker-Daemon startet beim Paket-Update automatisch neu, laufende Container werden dabei je nach restart-Policy automatisch neu gestartet.

Update für Docker-Compose-Stacks prüfen

Nach dem Engine-Update sollte auch geprüft werden, ob alle laufenden Container-Images aktuell sind. Ein reines Engine-Update patcht nicht automatisch veraltete Images innerhalb der Container:

cd /pfad/zum/compose-projekt
docker compose pull
docker compose up -d
docker image prune -f

docker compose pull lädt die neuesten Images gemäß der im Compose-File hinterlegten Tags, docker compose up -d ersetzt die laufenden Container durch die aktualisierten Images und docker image prune -f entfernt anschließend ungenutzte alte Image-Layer, um Speicher freizugeben.

Update verifizieren

1. docker version ausführen und prüfen, dass sowohl Client als auch Server auf einer gepatchten Version stehen.
2. docker ps mit der vorher gesicherten Container-Liste abgleichen, alle erwarteten Container müssen wieder laufen.
3. Anwendungs-Logs der wichtigsten Container kurz prüfen (docker logs <container>), um Startprobleme frühzeitig zu erkennen.
4. Bei Docker Desktop (macOS/Windows): Version im Docker-Desktop-Menü prüfen, mindestens 4.85.x für den vollständigen CVE-2026-17106-Fix.
5. Bei Nutzung von Docker Sandboxes (z. B. für KI-Agenten-Workflows): sicherstellen, dass mindestens Version 0.38.0 installiert ist.

Dauerhafte Update-Routine etablieren

Ein einmaliges Update löst das Grundproblem nicht. Sinnvoll ist eine feste Routine:

1. Docker-Engine-Release-Notes monatlich prüfen oder einen RSS-Reader auf die offiziellen Docker-Security-Announcements ansetzen.
2. Für Container-Images ein Update-Werkzeug wie Diun oder WUD einsetzen, das über verfügbare neue Image-Versionen benachrichtigt, statt automatisch und unkontrolliert zu aktualisieren.
3. Kritische Produktivsysteme in ein separates Wartungsfenster mit vorheriger Testumgebung einplanen.
4. docker cp in automatisierten Pipelines wo möglich durch Bind-Mounts oder Volumes ersetzen, die dieses Risiko strukturell umgehen.
5. Backups vor jedem grosseren Engine-Versionssprung nicht als Formalität, sondern als festen Pflichtschritt behandeln.

Passende Anleitungen auf S-EDV

1. Docker-Container automatisch aktualisieren nach dem Watchtower-Aus: Diun, WUD und Renovate im Vergleich
2. Docker und Docker Compose auf Linux installieren (Ubuntu/Debian): die Self-Hosting-Grundlage

Quellen

1. Imperva: CopyEscape - Taking Over Docker Hosts with docker cp
2. Docker Docs: Docker Engine version 29 release notes
3. NHS Digital Cyber Alert CC-4828: Docker Releases Security Updates for Docker Copy Functionality