Wann haben Sie das letzte Mal unter die Haube der von Ihnen verwendeten Docker-Container-Images geschaut? Denn hier ist die unschöne Wahrheit: Jede FROM-Anweisung, jedes kopierte Binary und jedes installierte Paket, das Ihren Container bildet, ist ein potenzieller Angriffsvektor.
Das bedeutet: Wenn Sie Ihre Container-Image-Layer und Build-Time-Abhängigkeiten nicht regelmäßig überprüfen, gehen Sie wahrscheinlich ein viel höheres Risiko ein, als Ihnen bewusst ist.
CVEs (Common Vulnerabilities and Exposures), unsichere Basis-Images, hartkodierte Secrets und übermäßige Berechtigungen sind nur einige der Wege, auf denen Angreifer eindringen können. Und das sollte für Organisationen wie die Ihre ein Anliegen sein.
Tatsächlich ergab der „2024 State of Container Security Report“ von Red Hat, der 600 DevOps-, Engineering- und Sicherheitsexperten befragte, dass fast die Hälfte der Teams (42 %) zugibt, dass Containersicherheit ihnen schlaflose Nächte bereitet.
Von Container-Laufzeit-Schwachstellen bis hin zu CVEs, die kritische GPU-Workloads betreffen, beleuchtet dieser Artikel neun der wichtigsten und am häufigsten übersehenen Docker-Containerschwachstellen.
Was sind Docker-Containerschwachstellen?
Eine Docker-Containerschwachstelle ist jede Schwäche, Fehlkonfiguration oder jeder Fehler innerhalb eines Container-Images, der Laufzeit oder der zugrunde liegenden Infrastruktur, den Angreifer ausnutzen können, um die Sicherheit zu kompromittieren. Dies umfasst sowohl bekannte CVEs als auch übersehene Probleme wie unsichere Standardeinstellungen, offengelegte Secrets oder übermäßige Berechtigungen.
Die Geschwindigkeit und Portabilität, die Docker-Container für Entwickelnde so leistungsfähig machen, können sie auch zu einem Albtraum für Sicherheitsteams werden lassen. Zum Beispiel mag das Pulling eines Images mit dem „latest“-Tag oder das Ausführen von Containern als Root zunächst harmlos erscheinen. In der Praxis sind dies jedoch genau die Art von Einfallstoren, nach denen Angreifer suchen.
Eine Schwachstelle ist, vereinfacht ausgedrückt, alles in Ihrer Container-Konfiguration, was es jemandem leichter macht, einzudringen.
Vor diesem Hintergrund erläutern wir die neun häufigsten und gefährlichsten Docker-Container-Schwachstellen, auf die Sie achten müssen.
Die Top 9 Schwachstellen in Docker-Containern
Die folgenden neun Schwachstellen sind aktive CVEs und weit verbreitete Fehlkonfigurationen, die in Produktionsumgebungen beobachtet werden. Jede stellt einen praktischen Bedrohungspfad dar, der zu einer Kompromittierung des Containers, Host-Zugriff oder lateraler Bewegung in Ihrer Infrastruktur führen kann.
Schlüsseln wir sie auf.
1. runC- und Docker-Container-Breakout-Schwachstellen
RunC ist eine „Low-Level“-Container-Laufzeitumgebung, die hauptsächlich von „High-Level“-Container-Laufzeitumgebungen wie Docker verwendet wird, um Container zu starten und auszuführen. Im Laufe der Jahre gab es mehrere runC- und Docker-Container-Breakout-Schwachstellen, die zu Angriffen geführt haben.
Eine bedeutende, CVE-2019-5736, wurde im Februar 2019 entdeckt. Diese Schwachstelle ermöglichte es einem Angreifer, eine runC-Bereitstellung, die eine Docker-Version vor 18.09.2 ausführt, durch Überschreiben des Host-runC-Binärprogramms auszunutzen und so den Host-Root-Zugriff zu kompromittieren.
Obwohl es sich um eine alte Schwachstelle handelt (6 Jahre alt Stand 2025), sind viele Teams ihr immer noch ausgesetzt, insbesondere in Umgebungen mit ungepatchten oder veralteten Docker-/runC-Versionen, Benutzerdefinierten oder geforkten Laufzeitumgebungen usw.
Eine kritische Nuance bei der CVE-2019-5736-Schwachstelle ist, dass der Container-Prozess als Root-Benutzer ausgeführt werden muss. Angenommen, Container würden als Nicht-Root-Container ausgeführt (z. B. mit USER 1000 im Dockerfile oder securityContext.runAsNonRoot: true in Kubernetes). In diesem Fall können Angreifer den Überschreibungspfad nicht auslösen, da ihnen die notwendigen Berechtigungen fehlen, weshalb es wichtig ist, Ihre Container nicht als Root-Benutzer auszuführen.
Seit 2019 sind weitere runC- und Docker-Container-Breakout-Schwachstellen aufgetaucht, einige mit geringer und einige mit kritischer Schwere:
- CVE-2024-21626: Container-Breakout durch runC process.cwd & geleakte fds
- CVE-2024-45310: Container-Breakout zum Erstellen leerer Dateien oder Verzeichnisse
- CVE-2024-23651: Buildkit Mount-Cache-Race
- CVE-2024-23652: Buildkit Build-Time Container Teardown Arbitrary Delete
- CVE-2024-23653: Buildkit GRPC SecurityMode Berechtigungsprüfung
Die Behebung dieser Sicherheitslücken erfordert ein Upgrade der betroffenen Docker-Container auf eine gepatchte Version.
HINWEIS: Wenn Sie unsicher sind, welche runC-Version Sie in Ihrer Umgebung haben, sollte die Ausführung von docker version die Version als Teil der Ausgabe anzeigen:
Schweregrad: Niedrig → Kritisch
2. CVE-2025-9074: Unauthentifizierter Zugriff auf die Docker Engine API von Containern aus
Die Docker Engine API bietet eine programmatische Schnittstelle zur Interaktion mit dem Docker-Daemon und zur Verwaltung von Docker-Objekten. Sie ist in allen Docker-Tools vorhanden, einschließlich Docker Desktop.
CVE-2025-9074 ist eine kritische Server-Side Request Forgery (SSRF)-ähnliche Schwachstelle in Docker Desktop. Mit dieser Schwachstelle können Container standardmäßig über das konfigurierte Docker-Subnetz unter 192.168.65.7:2375 auf die Docker Engine API zugreifen, selbst wenn „Enhanced Container Isolation“ aktiviert ist. Dies gilt auch mit oder ohne aktivierte Option „Expose daemon on tcp://localhost:2375 without TLS“.
Die CVE-2025-9074 betrifft nur macOS- und Windows-Maschinen. Während die meisten Produktionssysteme unter Linux laufen, wie z. B. Docker, verwenden einige auch Windows Server (insbesondere wenn sie Windows-Container benötigen).
Angreifer können diese CVE mit nur diesen drei Zeilen Python-Code unten ausnutzen:
The code above connects to the Docker daemon via TCP socket and runs a new Alpine container that creates a file exploit and mounts it to the host directory /Users/<username>. With that, when the container writes to the /mnt/exploit file, it writes to host /Users/<username>/exploit.
Ein Angreifer kann das Skript modifizieren, um alles zu tun, was die Docker Engine kann, einschließlich der Steuerung anderer Container, der Erstellung neuer Container, der Verwaltung von Images usw.
Wenn Sie Docker Desktop unter macOS oder Windows verwenden, stellen Sie sicher, dass Sie auf die neueste Version aktualisieren, da diese Schwachstelle in Version 4.44.3 behoben wurde.
Schweregrad: Kritisch
3. CVE-2022-0847: Dirty Pipe (Linux Kernel Escape)
Die CVE-2022-0847 Linux-Kernel-Schwachstelle resultiert aus einem Fehler in der Logik der pipe_buffer.flags im Pipe-Code des Kernels, der es einem böswilligen Akteur ermöglicht, in schreibgeschützte Dateien zu schreiben und so Schutzmechanismen wie O_RDONLY und immutable zu umgehen. Anschließend können sie ihre Privilegien eskalieren.
Obwohl es sich nicht um eine Container-spezifische Schwachstelle handelt, kann sie aus einem nicht privilegierten Linux-Container heraus genutzt werden, um Binärdateien wie /usr/bin/sudo auf dem Host zu überschreiben, Backdoors einzuschleusen und für die Verkettung von Exploits verwendet werden.
Die einzige bekannte Behebung für diese Schwachstelle ist die Aktualisierung Ihrer Linux-Hosts auf gepatchte Kernel-Versionen.
Schweregrad: Hoch
4. Unsichere Basis-Images
Basis-Images sind die Grundlage jedes Containers, den Sie erstellen, und wenn sie anfällig sind, ist es auch Ihre Anwendung. Leider verwenden viele Teams beim Erstellen von Containern immer noch Image-Tags wie ubuntu:latest oder node:alpine, ohne zu wissen, dass diese Tags bewegliche Ziele sind.
Das neueste Image, das Ihr Container heute verwendet, kann sich von dem unterscheiden, das er morgen verwendet. Dies kann unerwartete Sicherheitslücken einführen.
Um diese Schwachstelle zu mindern, verweisen Sie auf spezifische, vertrauenswürdige Versionen (z. B. FROM debian:bullseye-20230912), anstatt Tags wie latest zu verwenden. Und während Sie vertrauenswürdige Versionen eines bestimmten Images verwenden, denken Sie daran, konsistent mit Tools wie Aikido Security zu scannen, um CVEs und AutoFix-Schwachstellen zu erkennen.
Sie sollten auch Images in Ihrer Container Registry scannen, um Schwachstellen zu beheben, bevor sie in Ihre Umgebung gelangen. Aikido kann auch Images in Ihrer Container Registry integrieren und scannen, sei es Docker Hub oder Harbor.
Schweregrad: Niedrig → Kritisch (Abhängig von den Container-Images und der Nutzung)
5. Uneingeschränkter Docker Socket-Zugriff
Das Mounten des Docker Sockets, der sich normalerweise unter (/var/run/docker.sock) befindet, in einen Container ist eine der gefährlichsten Fehlkonfigurationen in Container-Umgebungen. Dies gewährt dem Container vollen Zugriff auf die Docker Engine API, wodurch er den gesamten Host kontrollieren kann. Das ist an sich nicht schlecht; jedoch könnte ein einzelner bösartiger Container bedeuten, dass ein Angreifer nun die Kontrolle über Ihren gesamten Host hat.
Teams mounten den Docker Socket manchmal, um "Docker-in-Docker"-Builds oder Monitoring-Tools die Verwaltung von Containern zu ermöglichen, aber es ist fast immer ein gefährlicher Shortcut.
Um diese Schwachstelle zu mindern, sollten Sie den Docker Socket niemals in Container mounten. Wenn Sie Docker-in-Docker-Funktionalität benötigen, sollte diese in streng kontrollierten Build-Umgebungen unter Verwendung von rootless Docker, gVisor oder Kata Containers isoliert werden.
Wenn Sie Kubernetes verwenden, sollten Sie Pod Security Standards oder Admission Policies durchsetzen, um Containern den Zugriff auf Host-Level-Ressourcen wie den Docker Socket zu verwehren.
Schweregrad: Kritisch
6. CVE-2025-23266: NVIDIA AI-Schwachstelle (GPU-Zugriffsfehler)
AI und ML sind alles, worüber wir im letzten Jahr gesprochen haben. Dies liegt daran, dass sie verändert haben, wie wir generell arbeiten und leben.
CVE-2025-23266 ist eine Container-Escape-Schwachstelle, die das NVIDIA Container Toolkit und den GPU Operator betrifft, welche uns ermöglichen, GPU-beschleunigte Container zu erstellen und auszuführen.
Das NVIDIA Container Toolkit verwendet OCI (Open Container Initiative)-Hooks (Benutzerdefinierte Skripte oder Binärdateien), um Container für den GPU-Zugriff zu konfigurieren. Einer dieser Hooks, enable-cuda-compat, erbt Umgebungsvariablen vom Container. Dies eröffnet einem Angreifer die Möglichkeit, ein bösartiges Image zu erstellen, das LD_PRELOAD so setzt, dass es auf eine bösartige Shared Library verweist.
Wenn der privilegierte Hook ausgeführt wird, wird die Bibliothek auf dem Host außerhalb der Sandbox des Containers geladen, wodurch dem Angreifer effektiv Root-Zugriff auf dem Knoten gewährt wird.
In Multi-Tenant-GPU-Clustern entsteht dadurch ein ernsthaftes Risiko von Cross-Tenant-Datenlecks und Node-Kompromittierung.
NVIDIA hat gepatchte Versionen beider Komponenten veröffentlicht. Ein Upgrade auf Toolkit v1.17.8 und GPU Operator 25.3.1 oder das Deaktivieren eines optionalen Hooks mindert die Schwachstelle.
Schweregrad: Wichtig
7. Offengelegte Secrets
Der 2025 IBM Cost of a Data Breach Report zeigt, dass Datenlecks, die durch kompromittierte Zugangsdaten verursacht wurden, am längsten brauchten, um identifiziert und eingedämmt zu werden. Angesichts der durchschnittlichen Kosten eines Datenlecks von 4,4 Millionen US-Dollar können es sich Unternehmen nicht leisten, offengelegte Secrets zu haben.
Dennoch gehören sie immer noch zu den häufigsten Fehlern, die Entwickelnde machen. Diese Secrets umfassen sensible Zugangsdaten wie API-Schlüssel, Passwörter, Verschlüsselungsschlüssel, private Schlüssel und mehr, die Angreifenden den Zugriff auf oder den Diebstahl vertraulicher Daten ermöglichen könnten.
Entwickelnde können Secrets in Docker Containern leaken über:
- Dockerfiles (ENV- oder ARG-Anweisungen)
- .env-Dateien, die in Image-Layer kopiert werden, usw.
Das Beängstigende daran ist, dass selbst nach dem Löschen eines Containers die Secrets zugänglich bleiben können, wenn das Image noch vorhanden ist (oder in ein Repository gepusht wurde).
Die Wahrscheinlichkeit, dass Ihre Organisation Secrets geleakt hat, ist hoch. Aber was können Sie jetzt dagegen tun?
Nun, Sie können und sollten:
- Alle aktiven Secrets finden und dann
- Verhindern, dass neue in die Produktion gelangen.
Es gibt auch Lösungen, die eine Live-Secret-Detection-Funktion bieten, die Ihnen helfen kann, potenzielle Risiken offengelegter Secrets zu bewerten.
Schweregrad: Hoch
8. Container-Privilegien-Schwachstellen
Wie bereits erwähnt, sollten Sie Container nicht als Root-Benutzer ausführen. Obwohl dies nicht automatisch Zugriff auf den Host gewährt, wie Sie gesehen haben, erhöht es das Risiko eines Ausbruchs erheblich, wenn es mit anderen Schwachstellen wie CVE-2022-0492 oder Fehlkonfigurationen bei Volume-Mounts und Capabilities kombiniert wird.
Über das Ausführen von Containern als Root-Benutzer hinaus gibt es weitere Möglichkeiten, wie ein Container über Privilegien angreifbar sein kann. Dies gilt insbesondere bei der Verwendung eines Container-Orchestrators wie Kubernetes, der Container automatisch erstellt, modifiziert und löscht.
Mit CVE-2023-2640 und CVE-2023-32629 kann ein Angreifender einen nicht-privilegierten Container mit Volume-Mount nutzen, um Privilegien zu eskalieren.
In Kubernetes würden Sie den Security Context verwenden, um Privilegien- und Zugriffssteuerungseinstellungen für einen Container zu definieren.
Im obigen Security Context:
- runAsNonRoot: true: Stellt sicher, dass der Container nicht als UID 0 startet
- runAsUser: 1000: Führt den Container explizit als Nicht-Root-Benutzer aus
- allowPrivilegeEscalation: false: Blockiert setuid oder andere Eskalationen
- capabilities.drop: [ALL]: Entfernt standardmäßig alle Linux-Capabilities
Die Verwaltung von Container-Privilegien und -Zugriffen erfordert ein Verständnis des Verhaltens Ihrer Anwendung. Wenn Sie beispielsweise keine Schreibvorgänge auf der Festplatte ausführen, sollten Sie alle zugehörigen Volumes als schreibgeschützt mounten, was die Angriffsfläche weiter reduziert.
Lesen Sie unseren Leitfaden zu Container-Privilegieneskalationsschwachstellen und wie Sie sich davor schützen können.
Schweregrad: Hoch → Kritisch
9. gh0stEdit: Schwachstelle bei schichtbasiertem Zugriff
Docker-Images sind so konzipiert, dass ihre EndBenutzer den Inhalt eines Images klar bewerten und einsehen können, bevor sie es ausführen.
Doch im Fall von gh0stEdit spielt diese Sichtbarkeit keine Rolle.
Obwohl keine formale CVE, beschreibt gh0stEdit (Name von seinen Forschenden gegeben) eine neuartige Schwachstelle, bei der ein Angreifer Docker-Images (selbst wenn sie mit Docker Content Trust signiert sind) manipulieren kann, ohne die Image-Signatur zu brechen oder von statischen/dynamischen Scans erkannt zu werden.
Abbildung 1: Umgehung der Docker-Image-Integrität: Ebenen geändert, Manifest unverändert. Quelle (Hackernoon)
Diese Manipulation ist möglich, weil Docker sich auf das Manifest konzentriert (die „Rezeptur“, die Image-Ebenen und deren Digests auflistet) und nicht auf jede einzelne Datei innerhalb jeder Ebene.
Wenn ein Angreifer ein bösartiges Skript in eine Ebene injiziert, läuft der Container und umgeht dabei das Dockerfile, den Build-Prozess und die Registry-Prüfungen. Es kann sich unbemerkt durch Ihr gesamtes System verbreiten.
Die Behebung und Verteidigung gegen gh0stEdit umfasst mehrere Schritte, darunter:
- Container-Images immer aus vertrauenswürdigen Quellen neu erstellen
- Signierung und Verifizierung von Container-Images mit Tools wie cosign
- Schwachstellen- und Inhaltsscanning mit Tools wie Aikido ergänzt Open-Source-Scanner mit Benutzerdefinierten Regeln, schließt Lücken und deckt Sicherheitslücken auf.
- Einsatz eines Admission Controllers, um zu verhindern, dass unsignierte oder ungeprüfte Images in Ihrem Cluster ausgeführt werden.
Schweregrad: Niedrig → Kritisch (Abhängig von den Container-Images und der Angriffsfläche)
Aufbau einer resilienten Docker-Sicherheitslage
Wie wir in diesem Artikel untersucht haben, können Schwachstellen wie runC Container-Breakouts, ungeprüfte Basis-Images, exponierte Secrets und übermäßige Privilegien Ihre gesamte Umgebung unbemerkt untergraben.
Die Implementierung einer resilienten Docker-Sicherheitslage bedeutet, über einfache Checkbox-Scans hinauszugehen hin zu kontextuellen, laufzeitbewussten, richtliniengesteuerten Abwehrmaßnahmen, die Schwachstellen automatisch finden und beheben.
Bei Aikido lieben wir etablierte Open-Source-Projekte wie Trivy, Syft und Grype. Wir wissen aber auch aus Erfahrung, dass die isolierte Nutzung keine besonders gute Entwicklererfahrung ist.
Aikido erweitert diese Projekte mit Benutzerdefinierten Regeln, um Lücken zu schließen und Sicherheitslücken aufzudecken, die Sie sonst nicht finden könnten. Im Gegensatz zur Verkettung verschiedener Open-Source-Tools befreit Aikido Sie davon, ein Scanning-Skript zu erstellen oder einen Benutzerdefinierten Job in Ihrer CI/CD zu konfigurieren.
Es gibt immer mehr über Docker-Sicherheit zu lernen. Um weitere Ihrer Fragen zur Absicherung von Docker zu beantworten, sehen Sie sich unsere no-BS Docker-Sicherheits-Checkliste für den schwachstellenbewussten Entwickelnden an.
Weiterlesen:
Die 7 häufigsten Cloud-Sicherheitslücken
Die 10 wichtigsten Webanwendungs-Sicherheitslücken, die jedes Team kennen sollte
Die 9 häufigsten Kubernetes-Sicherheitslücken und Fehlkonfigurationen
Die häufigsten Code-Sicherheitslücken in modernen Anwendungen
Die 10 häufigsten Python-Sicherheitslücken, die Entwickelnde vermeiden sollten
Die häufigsten JavaScript-Sicherheitslücken in modernen Webanwendungen
Die 9 häufigsten Sicherheitslücken in der Software-Lieferkette erklärt
