Kritische Docker-Schwachstelle ermöglicht Angriffe auf Host-Systeme

Thales warnt vor CVE-2026-17106: Eine Sicherheitslücke im Docker-Befehl „docker cp“ ermöglicht Angreifern, Dateien auf Host-Systemen zu manipulieren und unter bestimmten Voraussetzungen Schadcode mit Root-Rechten auszuführen. Auch KI-Agenten und automatisierte Entwicklungsumgebungen sind betroffen.

Ein vermeintlich harmloser Kopiervorgang kann ausreichen, um die Sicherheitsgrenzen zwischen Docker-Containern und Host-Systemen zu überwinden. Sicherheitsforscher des Imperva Red Teams von Thales haben mit CopyEscape (CVE-2026-17106) eine Schwachstelle aufgedeckt, durch die Angreifer Dateien außerhalb des vorgesehenen Zielverzeichnisses erstellen oder überschreiben können. Besonders kritisch ist die Sicherheitslücke für Entwicklungsumgebungen, CI/CD-Pipelines und KI-Agenten, die regelmäßig Daten zwischen isolierten Containern und Host-Systemen austauschen.

Die Schwachstelle betrifft den Docker-Befehl docker cp, mit dem Dateien zwischen Containern und Host-Systemen kopiert werden. Docker bestätigte, dass auch der Befehl sbx cp in Docker Sandboxes betroffen war.

Die Sicherheitslücke wurde am 10. August 2026 mit Docker Engine 29.7.2 im Rahmen des Docker Desktop Release 4.86.0 behoben. Bereits zuvor hatte Docker erste Korrekturen veröffentlicht. Für Docker Sandboxes steht seit Version 0.38.0 vom 6. August 2026 eine entsprechende Fehlerbehebung bereit.

Unternehmen sollten sicherstellen, dass ihre Systeme mindestens Docker Engine und CLI 29.7.2 beziehungsweise Docker Desktop 4.86.0 verwenden.

Wenn ein Kopiervorgang zur Sicherheitslücke wird

Der Befehl docker cp gehört zum Standardwerkzeug vieler Entwickler und Administratoren. Er ermöglicht es, Build-Artefakte, Protokolle, Testergebnisse oder andere Dateien aus einem Container auf das Host-System zu übertragen.

Genau dieser alltägliche Vorgang kann jedoch zum Einfallstor werden. Ein Angreifer, der einen laufenden Container kontrolliert, kann die Schwachstelle ausnutzen, sobald ein Benutzer oder ein automatisierter Prozess bestimmte Dateien aus diesem Container kopiert.

Dabei gelingt es, die vorgesehenen Verzeichnisgrenzen zu umgehen. Statt Dateien ausschließlich am ausgewählten Zielort abzulegen, kann die Docker-CLI dazu gebracht werden, Daten an anderen Stellen des Host-Dateisystems zu schreiben.

Besonders problematisch: Die Schreiboperation erfolgt mit den Berechtigungen des Benutzers oder Prozesses, der den Docker-Befehl ausführt. Damit entsteht eine Angriffsmöglichkeit, die weit über die eigentliche Containerumgebung hinausreicht.

Zwei Angriffsszenarien: Manipulation von Host-Dateien und Codeausführung

Die Sicherheitsforscher von Thales identifizierten zwei wesentliche Auswirkungen von CVE-2026-17106.

1. Beliebige Host-Dateien überschreiben

Ein kompromittierter Container kann den Kopiervorgang nutzen, um Dateien auf dem Host-System zu erstellen oder zu verändern, sofern der ausführende Benutzer über entsprechende Schreibberechtigungen verfügt. Mögliche Angriffsziele sind:

• Shell-Konfigurationen und Startskripte
• ausführbare Programme und Systemdateien
• SSH-Konfigurationen
• Quellcode und Entwicklungsverzeichnisse
• Konfigurationsdateien für Cloud-Dienste
• Mechanismen zur dauerhaften Verankerung von Schadsoftware

Dadurch können Angreifer nicht nur Entwicklungsumgebungen manipulieren, sondern auch Voraussetzungen für spätere Angriffe schaffen.

2. Schadcode mit Benutzer- oder Root-Rechten ausführen

Noch gravierender sind die möglichen Folgen für die Codeausführung. Unter macOS kann ein Angreifer beispielsweise Startskripte oder andere Dateien manipulieren, deren spätere Ausführung Schadcode mit den Rechten des angemeldeten Benutzers startet.

Unter Linux verschärft sich die Situation, wenn docker cp mit erhöhten Berechtigungen ausgeführt wird. In einem Proof of Concept gelang es den Forschern, die ausführbare Datei runc zu überschreiben. runc ist eine zentrale Komponente zur Ausführung von Containern.

Wird die manipulierte Binärdatei anschließend durch einen Docker-Prozess gestartet, kann der eingeschleuste Code mit Root-Rechten ausgeführt werden.

Entscheidend ist dabei, dass der Angriff keine direkte Übernahme des Docker-Daemons voraussetzt. Stattdessen missbraucht er die Berechtigungen der Docker-CLI, um Dateien auf dem Host zu verändern.

Technische Ursache: Zwei Schwachstellen ermöglichen den Ausbruch

CopyEscape basiert auf der Verkettung zweier Sicherheitsprobleme innerhalb der Archivverarbeitung von Docker.

Beim Kopieren einer Datei aus einem Container erstellt der Docker-Daemon zunächst ein TAR-Archiv. Dieses wird anschließend von der Docker-CLI auf dem Zielsystem entpackt. Die Sicherheitsforscher identifizierten zwei Schwachstellen in diesem Ablauf.

Race Condition bei der Archivgenerierung

Während Docker die Dateien eines laufenden Containers verarbeitet, kann ein Angreifer dessen Dateisystem gezielt verändern. Durch diese sogenannte Race Condition beziehungsweise einen Time-of-Check-to-Time-of-Use-Fehler (TOCTOU) lässt sich erreichen, dass Docker ein inkonsistentes TAR-Archiv erzeugt. Ein Verzeichniseintrag kann dabei zunächst als reguläres Verzeichnis erkannt werden, während er bei einer späteren Verarbeitung bereits durch einen symbolischen Link ersetzt wurde.

Fehlerhafte Prüfung symbolischer Links

Die zweite Schwachstelle betrifft das Entpacken des Archivs durch die Docker-CLI.

Hier konnte ein präparierter symbolischer Link dazu führen, dass Dateien außerhalb des vorgesehenen Zielverzeichnisses geschrieben wurden. Die Sicherheitsprüfung validierte einen konstruierten Dateipfad, während die eigentliche Dateisystemoperation einen anderen Pfad verwendete. In Kombination ermöglichen beide Fehler, dass ein vom Angreifer kontrollierter Container Schreiboperationen auf dem Host-System auslöst. Die Docker-CLI wird dadurch unbeabsichtigt zum Werkzeug des Angreifers. CI/CD-Pipelines und Incident Response besonders gefährdet Die Schwachstelle betrifft keineswegs nur einzelne Entwicklerarbeitsplätze. Gerade in automatisierten IT-Umgebungen werden regelmäßig Dateien aus Containern extrahiert. Dazu gehören beispielsweise Build-Ergebnisse, Testberichte und Logdateien.

Besonders relevant ist CopyEscape deshalb für:

• CI/CD-Systeme und automatisierte Build-Prozesse
• Entwickler-Workstations unter Linux und macOS
• privilegierte Administrations- und Wartungsskripte
• automatisierte Containerverwaltung
• forensische Analysen und Incident-Response-Prozesse

Ein besonders kritisches Szenario ergibt sich bei der Untersuchung bereits kompromittierter Container. Sicherheitsteams kopieren im Rahmen einer forensischen Analyse häufig Protokolle, verdächtige Dateien oder andere Beweismittel aus einem betroffenen Container. Genau dieser Vorgang könnte die vorbereitete Angriffskette auslösen.

Damit wird ausgerechnet eine Sicherheitsmaßnahme zum potenziellen Auslöser einer weiteren Kompromittierung.

Angreifer müssten lediglich sicherstellen, dass sich die präparierten Dateien im Container befinden und später durch einen entsprechenden Kopiervorgang verarbeitet werden.

Auch KI-Agenten und Docker Sandboxes betroffen

Die Auswirkungen von CopyEscape reichen über klassische Containerumgebungen hinaus. Mit Docker Sandboxes stellt Docker isolierte Umgebungen bereit, in denen unter anderem KI-gestützte Coding-Agenten arbeiten können. Um Dateien zwischen diesen Agentenumgebungen und dem Host-System auszutauschen, wird der Befehl sbx cp verwendet. Docker bestätigte, dass auch dieser Kopiermechanismus von CVE-2026-17106 betroffen war. Damit entsteht ein zusätzliches Risiko für Unternehmen, die KI-Agenten zur automatisierten Softwareentwicklung einsetzen. Erstellt ein kompromittierter oder nicht vertrauenswürdiger Coding-Agent ein präpariertes Artefakt, könnte dessen Übertragung auf den Host einen vergleichbaren Angriff ermöglichen. Gerade agentische Entwicklungsumgebungen sind auf den regelmäßigen Austausch von Quellcode, Konfigurationsdateien und Build-Ergebnissen angewiesen. Die zunehmende Automatisierung solcher Abläufe erhöht deshalb die Bedeutung einer konsequenten Absicherung sämtlicher Dateiübertragungen zwischen Sandbox und Host. Docker hat die entsprechende Schwachstelle in Docker Sandboxes mit Version 0.38.0 vom 6. August 2026 behoben.

Welche Schutzmaßnahmen Unternehmen ergreifen sollten

Die wichtigste Maßnahme besteht darin, betroffene Docker-Installationen auf einen abgesicherten Versionsstand zu aktualisieren.

Thales empfiehlt ein Upgrade auf mindestens folgende Versionen:

• Docker Engine und CLI: Version 29.7.2 oder höher
• Docker Desktop: Version 4.86.0 oder höher
• Docker Sandboxes: Version 0.38.0 oder höher

Falls eine Aktualisierung nicht unmittelbar möglich ist, sollten Unternehmen zusätzliche Schutzmaßnahmen umsetzen. Dazu gehört insbesondere, keine Dateien aus laufenden, nicht vertrauenswürdigen oder bereits kompromittierten Containern auf sensible Host-Systeme zu kopieren. Das vorherige Stoppen eines Containers verhindert die während der Archivgenerierung ausgenutzte Race Condition, ersetzt allerdings keine grundlegende Absicherung der Archivverarbeitung. Darüber hinaus sollten Unternehmen auf die Ausführung von docker cp mit Root-Rechten verzichten, sofern diese nicht zwingend erforderlich sind. Für die Analyse verdächtiger Container empfiehlt sich außerdem der Einsatz isolierter Untersuchungsumgebungen, etwa separater virtueller Maschinen oder entsprechend eingeschränkter Benutzerkonten.

Fazit: Auch Werkzeuge zur Dateiübertragung sind sicherheitskritisch

CopyEscape verdeutlicht, dass Container-Sicherheit nicht allein von der Isolation durch Namespaces, virtuelle Maschinen oder den Docker-Daemon abhängt. Ebenso entscheidend sind die Werkzeuge, die Daten über diese Sicherheitsgrenzen hinweg transportieren.

Der Befehl docker cp verbindet ein potenziell vom Angreifer kontrolliertes Dateisystem mit einem Extraktionsprozess, der über weitreichende Berechtigungen auf dem Host verfügen kann. CVE-2026-17106 zeigt, welche Folgen entstehen, wenn die Integrität eines Archivs und die tatsächlichen Zielpfade beim Entpacken nicht ausreichend abgesichert werden.

Ein symbolischer Link und eine gezielt ausgenutzte Race Condition reichten aus, um die vorgesehene Sicherheitsgrenze zu überwinden. Julian Iavarone, Technical Consultant, Data and Application Security bei Thales, betont, dass die Extraktion von Archiven selbst als Sicherheitsgrenze betrachtet werden müsse. Einfache Pfadnormalisierungen und Zeichenfolgenvergleiche könnten diese Grenze nicht zuverlässig schützen, sobald symbolische Links und gleichzeitige Änderungen am Dateisystem ins Spiel kommen.

Stattdessen müssten Dateisystemoperationen technisch so begrenzt werden, dass der Betriebssystemkernel den zulässigen Schreibbereich durchsetzt.

Für Unternehmen ergibt sich daraus eine klare Konsequenz: Nicht nur Container selbst, sondern auch sämtliche automatisierten Transferprozesse zwischen Containern, KI-Agenten und Host-Systemen müssen Bestandteil der Sicherheitsarchitektur sein.

Das Imperva Red Team von Thales meldete die Schwachstelle im Rahmen einer koordinierten Offenlegung an Docker. Die beteiligten Unternehmen stimmten die Veröffentlichung mit der Bereitstellung entsprechender Sicherheitsupdates ab.