CopyEscape: Kritische Docker-Lücke CVE-2026-17106 bei docker cp
CVE-2026-17106, genannt CopyEscape, betrifft die Kopierfunktionen docker cp und sbx cp von Docker Engine, Docker CLI, Docker Desktop und Docker Sandboxes. Eine TOCTOU-Race im Archivpfad zusammen mit einer rein lexikalischen Zielpfadprüfung ohne echte Symlink-Auflösung erlaubt einem bösartigen laufenden Container, beim Kopieren Hostdateien zu überschreiben. Bei privilegiertem Kopieren unter Linux ist sogar Root-Codeausführung möglich.
Docker Engine und Docker CLI vor Version 29.7.2, Docker Desktop vor 4.86.0 sowie Docker Sandboxes vor 0.38.0 sind von einer neu bekannt gewordenen Schwachstelle betroffen, die unter dem Namen CopyEscape geführt wird. Die Lücke trägt die Kennung CVE-2026-17106 und wurde mit einem CVSS-Wert von 7.1 als hoch eingestuft. Wer eine der genannten Versionen produktiv im Einsatz hat, sollte die Aktualisierung zeitnah einplanen, denn ein Proof of Concept ist bereits öffentlich zugänglich.
Die Dringlichkeit ergibt sich vor allem daraus, dass die Lücke direkt am Kopiermechanismus zwischen Container und Host ansetzt und damit klassische Isolationsannahmen unterläuft. Zwar liegt bislang keine bestätigte aktive Ausnutzung in freier Wildbahn vor, doch angesichts des verfügbaren PoC-Codes und der potenziellen Auswirkung bis hin zur Root-Codeausführung ist zügiges Handeln angeraten. Teams, die docker cp regelmäßig in Automatisierung, Forensik oder CI-Pipelines nutzen, tragen ein besonders hohes Risiko.
Was ist CopyEscape?
CopyEscape bezeichnet eine Schwachstellenklasse in den Kopierfunktionen docker cp und sbx cp. Beide Befehle dienen dazu, Dateien zwischen einem laufenden Container und dem Hostsystem zu übertragen, etwa um Logdateien zu sichern, Konfigurationen einzuspielen oder Artefakte für die Weiterverarbeitung aus einem Container zu holen. Die Schwachstelle betrifft ausschließlich diesen Laufzeit-Kopiervorgang zwischen einem bereits gestarteten Container und dem Hostsystem. Die Build-Zeit-Anweisungen COPY und ADD in einem Dockerfile sind von CVE-2026-17106 ausdrücklich nicht betroffen, da sie einem anderen Codepfad folgen und zu einem Zeitpunkt greifen, an dem noch kein potenziell bösartiger Prozess im Container aktiv läuft. Diese Unterscheidung ist für die Einordnung des Risikos wichtig, denn viele automatisierte Build-Pipelines nutzen COPY und ADD intensiv, ohne dadurch direkt betroffen zu sein.
Technischer Hintergrund der Schwachstelle
Die Ursache liegt in einer Kombination aus zwei Schwächen, die erst im Zusammenspiel ihre volle Wirkung entfalten. Zum einen besteht ein TOCTOU-Race, also eine Race Condition zwischen dem Zeitpunkt der Prüfung und dem Zeitpunkt der tatsächlichen Verwendung eines Archivpfads während des Kopiervorgangs. Zum anderen erfolgt die Prüfung des Zielpfads rein lexikalisch, also auf Basis der Zeichenkette des Pfades, ohne dass eine echte Auflösung von Symlinks stattfindet. Eine lexikalische Prüfung erkennt zwar formal ungültige Pfadmuster, sie stellt aber nicht sicher, dass ein Pfadbestandteil zur Laufzeit tatsächlich noch auf das erwartete Verzeichnis zeigt. In der kurzen Zeitspanne zwischen Prüfung und Kopiervorgang kann ein bösartiger, laufender Container einen Pfadbestandteil im Archiv so manipulieren oder durch einen Symlink ersetzen, dass die Kopieroperation außerhalb des vorgesehenen Zielverzeichnisses landet. Der Docker-Daemon vertraut dabei auf das Ergebnis der vorherigen Prüfung, obwohl sich die Ausgangslage inzwischen verändert haben kann.
Mögliche Auswirkungen
Ein Angreifer, der Kontrolle über einen laufenden Container erlangt hat, etwa durch eine kompromittierte Anwendung oder ein manipuliertes Image, kann die Lücke ausnutzen, um beim nächsten docker cp Vorgang durch den Host beliebige Hostdateien zu überschreiben. Betroffen sein können dabei Konfigurationsdateien, Skripte oder andere Dateien, auf die der ausführende Benutzer Schreibzugriff besitzt. Geschieht dieser Kopiervorgang mit erhöhten Rechten, etwa im Rahmen privilegierter Automatisierung unter Linux, kann daraus im schlimmsten Fall eine vollständige Root-Codeausführung auf dem Hostsystem entstehen, indem beispielsweise sicherheitsrelevante Systemdateien oder Startskripte überschrieben werden. Damit reicht die Auswirkung deutlich über den eigentlichen Container hinaus und stellt die grundlegende Isolationsannahme zwischen Container und Host infrage.
Betroffene Produkte und Versionen
Die folgende Tabelle fasst die betroffenen Komponenten und die jeweiligen Fix-Versionen zusammen.
| Produkt | Betroffen bis Version | Behoben ab Version |
|---|---|---|
| Docker Engine | vor 29.7.2 | 29.7.2 |
| Docker CLI | vor 29.7.2 | 29.7.2 |
| Docker Desktop | vor 4.86.0 | 4.86.0 |
| Docker Sandboxes | vor 0.38.0 | 0.38.0 |
Empfohlene Sofortmaßnahmen
Voraussetzung für eine Ausnutzung ist ein bereits laufender, bösartiger oder kompromittierter Container, aus dem heraus ein Angreifer den Kopiervorgang manipulieren kann. Besonders kritisch ist das Szenario, wenn Administratoren oder Automatisierungssysteme docker cp mit erhöhten Rechten gegen verdächtige Container ausführen, etwa im Rahmen von Incident Response oder forensischer Analyse. Gerade in dieser Situation kehrt sich die eigentliche Absicht der Untersuchung ins Gegenteil um, da der vermeintlich isolierte Container aktiv den Host angreifen kann. Die folgenden Maßnahmen helfen, das Risiko bis zum vollständigen Update zu begrenzen und danach dauerhaft abzusichern.
- Docker Engine und Docker CLI auf Version 29.7.2 oder neuer aktualisieren
- Docker Desktop auf Version 4.86.0 oder neuer aktualisieren
- Docker Sandboxes auf Version 0.38.0 oder neuer aktualisieren
- Verdächtige oder kompromittierte Container vor jedem docker cp Zugriff stoppen
- Kein privilegiertes Kopieren mit docker cp gegen nicht vertrauenswürdige Container durchführen
- Forensische Analysen ausschließlich in isolierten, vom Produktivhost getrennten Umgebungen durchführen
- CI- und CD-Pipelines prüfen, ob docker cp oder sbx cp gegen dynamisch gestartete Container verwendet wird
- Automatisierungsskripte identifizieren, die docker cp mit erhöhten Rechten aufrufen
- Nach dem Update den vorliegenden Proof of Concept in einer Testumgebung nachvollziehen
- Monitoring für ungewöhnliche Dateiänderungen auf Docker-Hosts ergänzen
Da CVE-2026-17106 die vertraute Trennung zwischen Container und Host an einer zentralen Stelle aufweicht, sollten Update und Absicherung der beschriebenen Kopiervorgänge Vorrang vor anderen Wartungsarbeiten erhalten.
Passende Anleitungen auf S-EDV
Docker sicher aktualisieren: Schritt-für-Schritt-Anleitung
Docker Images mit Trivy scannen: Schwachstellen und SBOM
Quellen
Cyber Security News: CopyEscape Docker Vulnerability
