Die 9 größten Sicherheitslücken bei Docker Container

Wann haben Sie das letzte Mal einen Blick unter die Haube der von Ihnen verwendeten container geworfen? Denn hier ist die unangenehme Wahrheit: Jede FROM-Anweisung, jede kopierte Binärdatei und jedes installierte Paket, aus denen Ihr container besteht, container ein potenzieller Angriffsvektor. 

Das bedeutet, wenn Sie Ihre container -Layers und Build-Zeit-Abhängigkeiten nicht regelmäßig überprüfen, gehen Sie wahrscheinlich ein weitaus größeres Risiko ein, als Ihnen bewusst ist.

CVEs (Common Vulnerabilities and Exposures), unsichere Basisimages, fest codierte secrets und übermäßige Berechtigungen sind nur einige der Möglichkeiten, wie Angreifer eindringen können. Und das sollte für Unternehmen wie Ihres ein Grund zur Sorge sein.

Tatsächlich ergab der Bericht „2024 State of Container von Red Hat, für den 600 DevOps-, Engineering- und Sicherheitsexperten befragt wurden, dass fast die Hälfte der Teams (42 %) zugibt, dass sie container nachts wach hält. 

Von Schwachstellen in container bis hin zu CVEs, die kritische GPU-Workloads beeinträchtigen – dieser Artikel beschreibt neun der wichtigsten und häufig übersehenen container .

Was sind Container Docker Container ?

Eine container ist jede Schwachstelle, Fehlkonfiguration oder jeder Fehler innerhalb eines container , einer Laufzeitumgebung oder der zugrunde liegenden Infrastruktur, die Angreifer ausnutzen können, um die Sicherheit zu gefährden. Dazu gehören 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 Entwickler so leistungsstark machen, können sie für Sicherheitsteams auch zu einem Albtraum machen. Beispielsweise mag das Abrufen eines Images mit dem neuesten Tag oder das Ausführen von Containern als Root zunächst harmlos erscheinen. In der Praxis sind dies jedoch genau die Schwachstellen, nach denen Angreifer suchen.

Eine Schwachstelle ist, vereinfacht gesagt, alles in Ihrer container , was es jemandem, der versucht einzudringen, leichter macht.

Vor diesem Hintergrund wollen wir uns nun die neun häufigsten und gefährlichsten container ansehen, auf die Sie achten müssen.

Die 9 größten Schwachstellen in Docker-Containern

Die folgenden neun Schwachstellen sind aktive CVEs und weit verbreitete Fehlkonfigurationen, die in Produktionsumgebungen beobachtet wurden. Jede einzelne stellt eine praktische Bedrohung dar, die zu container , Host-Zugriff oder lateraler Bewegung in Ihrer Infrastruktur führen kann.

Schauen wir uns das genauer an.

1. Sicherheitslücken bei runC und Docker Container 

RunC ist eine container , die hauptsächlich von container wie Docker zum Erstellen und Ausführen von Containern verwendet wird. Im Laufe der Jahre haben wir mehrere container RunC- und container beobachtet, die zu Angriffen geführt haben. 

Eine schwerwiegende Schwachstelle, CVE-2019-5736, wurde im Februar 2019 entdeckt. Diese Schwachstelle ermöglichte es einem Angreifer, eine runC-Bereitstellung mit einer Docker-Version vor 18.09.2 auszunutzen, indem er die Host-runC-Binärdatei überschrieb und so den Root-Zugriff auf den Host kompromittierte. 

Obwohl es sich um eine alte Schwachstelle handelt (6 Jahre alt, Stand 2025), sind viele Teams immer noch davon betroffen, insbesondere in Umgebungen mit ungepatchten oder älteren Docker-/runC-Versionen, benutzerdefinierten oder geforkten Laufzeiten usw. 

Eine entscheidende Nuance der Sicherheitslücke CVE-2019-5736 besteht darin, dass der container als Root-Benutzer ausgeführt werden muss. Angenommen, Container würden als Nicht-Root-Container ausgeführt (z. B. mit USER 1000 in der Dockerfile oder securityContext.runAsNonRoot: true in Kubernetes). In diesem Fall können Angreifer den Überschreibungspfad nicht auslösen, da ihnen die erforderlichen Berechtigungen fehlen. Aus diesem Grund ist es wichtig, Ihre Container nicht als Root-Benutzer auszuführen.  

Seit 2019 sind weitere Sicherheitslücken container RunC- und container aufgetaucht, von denen einige einen geringen Schweregrad haben, andere hingegen kritisch sind:

• CVE-2024-21626: Container durch runC-Prozess.cwd und undichte fds 
• CVE-2024-45310: Container zum Erstellen leerer Dateien oder Verzeichnisse
• CVE-2024-23651: Buildkit-Mount-Cache-Wettlauf
• CVE-2024-23652: Buildkit-Build container – willkürliches Löschen
• CVE-2024-23653: Buildkit GRPC SecurityMode-Privilegienprüfung

Um diese Sicherheitslücken zu beheben, müssen die betroffenen Docker-Container auf eine gepatchte Version aktualisiert werden.

HINWEIS: Wenn Sie sich nicht sicher sind, welche Version von runC Sie in Ihrer Umgebung haben, sollten Sie mit dem Befehl „docker version“ die Version als Teil der Ausgabe erhalten:

Schweregrad: Niedrig → Kritisch

2. CVE-2025-9074: Docker Desktop – Nicht authentifizierter Zugriff auf die Docker Engine API aus Containern

Die Docker Engine API bietet eine programmatische Schnittstelle für die Interaktion mit dem Docker-Daemon und die Verwaltung von Docker-Objekten. Sie ist in allen Docker-Tools vorhanden, einschließlich Docker Desktop. 

CVE-2025-9074 ist eine kritische Schwachstelle in Docker Desktop, die einer serverseitigen Request-Fälschung (SSRF) ähnelt. 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 aktiviert ist. Dies gilt unabhängig davon, ob die Option „Daemon auf tcp://localhost:2375 ohne TLS freigeben” aktiviert ist oder nicht.

Die Sicherheitslücke CVE-2025-9074 betrifft nur macOS- und Windows-Rechner. Während die meisten Produktionssysteme unter Linux laufen, wie beispielsweise Docker, verwenden einige Windows Server (insbesondere, wenn sie die Verwendung von Windows-Containern erfordern).

Angreifer können diese CVE mit nur diesen drei Zeilen Python-Code 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 so ändern, dass es alles tun kann, 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 Sicherheitslücke in Version 4.44.3 behoben wurde.

Schweregrad: Kritisch  

3. CVE-2022-0847: Dirty Pipe ( Escape)

Die Linux-Kernel-Sicherheitslücke CVE-2022-0847 beruht auf einem Fehler in der pipe_buffer.flags-Logik des Pipe-Codes des Kernels, der es einem böswilligen Akteur ermöglicht, in schreibgeschützte Dateien zu schreiben und dabei Schutzmechanismen wie O_RDONLY und immutable zu umgehen. Anschließend kann er seine Berechtigungen erweitern. 

Es handelt sich zwar nicht um eine container Schwachstelle, sie kann jedoch von einem nicht privilegierten container aus genutzt werden, container Binärdateien wie /usr/bin/sudo auf dem Host container überschreiben, Backdoors einzuschleusen und für die Verkettung von Exploits verwendet zu werden.

Die einzige bekannte Lösung für diese Sicherheitslücke besteht darin, Ihre Linux-Hosts auf gepatchte Kernel-Versionen zu aktualisieren. 

Schweregrad: Hoch  

4. Unsichere Basis-Images

Basisimages sind die Grundlage jedes container erstellen. Sind diese anfällig, ist auch Ihre Anwendung anfällig. Leider verwenden viele Teams beim Erstellen von Containern immer noch Image-Tags wie „ubuntu:latest“ oder „node:alpine“, ohne zu erkennen, dass diese Tags sich ständig ändern. 

Das neueste Image, das Ihr container heute container , kann sich von dem unterscheiden, das er morgen verwendet. Dies kann zu unerwarteten Sicherheitslücken führen.  

Um diese Schwachstelle zu mindern, verweisen Sie auf bestimmte, 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, diese regelmäßig mit Tools wie Aikido zu scannen, um CVEs und AutoFix-Schwachstellen zu erkennen. 

Sie sollten auch Images in Ihrer container scannen, um Schwachstellen zu beheben, bevor sie in Ihre Umgebung gelangen. Aikido kann auch Images in Ihrer container integrieren und scannen, egal ob es sich um Docker Hub oder Harbor handelt. 

​

Schweregrad: Niedrig → Kritisch (abhängig von den container und der Verwendung)

5. Uneingeschränkter Socket Docker Socket

Das Mounten des socket, der sich normalerweise unter (/var/run/docker.sock) befindet, in einen container ist eine der gefährlichsten Fehlkonfigurationen in containerisierten Umgebungen. Dadurch erhält der container Zugriff auf die Docker Engine API und kann den gesamten Host kontrollieren. Das ist an sich nichts Schlimmes, aber ein einziger bösartiger container bedeuten, dass ein Angreifer nun die Kontrolle über Ihren gesamten Host hat. 

Teams mounten manchmal den socket „Docker-in-Docker”-Builds oder Überwachungstools zur Verwaltung von Containern socket ermöglichen, aber das ist fast immer eine gefährliche Abkürzung. 

Um diese Schwachstelle zu mindern, sollten Sie den socket niemals socket Container einbinden. Wenn Sie die 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-Sicherheitsstandards oder Zulassungsrichtlinien durchsetzen, um zu verhindern, dass Container auf Ressourcen auf Host-Ebene wie den socket zugreifen können. 

Schweregrad: Kritisch

6. CVE-2025-23266: NVIDIA-KI-Sicherheitslücke (GPU-Zugriffsfehler)

Im vergangenen Jahr haben wir ausschließlich über KI und ML gesprochen. Der Grund dafür ist, dass diese Technologien unsere Arbeitsweise und unser Leben insgesamt verändert haben. 

CVE-2025-23266 ist eineescape , die das NVIDIA Container und den GPU Operator betrifft, mit denen wir GPU-beschleunigte Container erstellen und ausführen können.

DasContainer verwendet OCI-Hooks (Open Container ) (benutzerdefinierte Skripte oder Binärdateien), um Container für den GPU-Zugriff zu konfigurieren. Einer dieser Hooks, enable-cuda-compat, übernimmt Umgebungsvariablen aus dem container. Dies eröffnet Angreifern die Möglichkeit, ein bösartiges Image zu erstellen, das LD_PRELOAD so einstellt, dass es auf eine betrügerische gemeinsam genutzte Bibliothek verweist.  

Wenn der privilegierte Hook ausgeführt wird, wird die Bibliothek auf dem Host außerhalb der Sandbox container geladen, wodurch der Angreifer effektiv Root-Zugriff auf den Knoten erhält. 

In Multi-Tenant-GPU-Clustern entsteht dadurch ein ernsthaftes Risiko für datenübergreifende Datenlecks und die Kompromittierung von Knoten.

NVIDIA hat gepatchte Versionen beider Komponenten veröffentlicht. Ein Upgrade auf Toolkit  v1.17.8  und GPU Operator 25.3.1 oder die Deaktivierung eines optionalen Hooks mindert die Sicherheitslücke.

Schweregrad: Wichtig  

7. Aufgedeckte Secrets

Der IBM-Bericht „ “ aus dem Jahr 2025 über die Kosten von Datenverstößen zeigt, dass Datenverstöße aufgrund kompromittierter Anmeldedaten am längsten zu identifizieren und einzudämmen waren. Angesichts der durchschnittlichen Kosten eines Datenverstoßes in Höhe von 4,4 Millionen US-Dollar können es sich Unternehmen nicht leisten, secrets preiszugeben. 

Dennoch gehören sie nach wie vor zu den häufigsten Fehlern, die Entwickler begehen. secrets diesen secrets sensible Anmeldedaten wie API-Schlüssel, Passwörter, Verschlüsselungsschlüssel, private Schlüssel und vieles mehr, die es Angreifern ermöglichen könnten, auf vertrauliche Daten zuzugreifen oder diese zu stehlen.

Entwickler können secrets Docker-Containern über folgende Wege preisgeben:

• Dockerfiles (ENV- oder ARG-Anweisungen)
• .env-Dateien, die in Bildlayer kopiert wurden, usw. 

Das Beängstigende daran ist, dass selbst nach container eines container die secrets weiterhin zugänglich bleiben secrets , wenn das Image noch vorhanden ist (oder in eine Registrierungsdatenbank übertragen wurde).

Die Wahrscheinlichkeit, dass Ihr Unternehmen secrets preisgegeben hat, secrets hoch. Aber was können Sie jetzt dagegen tun? 

Nun, das können und sollten Sie:

• Finde alle aktiven secrets dann 
• Verhindern Sie, dass neue Fehler in die Produktion gelangen. 

Es gibt auch einige Lösungen, die eine Live-Funktion zur Erkennung geheimer Informationen bieten, mit deren Hilfe Sie secrets Risiken durch offengelegte secrets bewerten können.

Schweregrad: Hoch

8. Sicherheitslücken bei Container

Wie bereits erwähnt, sollten Sie Container nicht als Root-Benutzer ausführen. Dies gewährt zwar nicht automatisch Zugriff auf den Host, erhöht jedoch, wie Sie gesehen haben, das Risiko eines Ausbruchs erheblich, wenn es mit anderen Schwachstellen wie CVE-2022-0492 oder Fehlkonfigurationen bei Volume-Mounts und -Fähigkeiten kombiniert wird. 

Neben der Ausführung von Containern als Root-Benutzer gibt es noch andere Möglichkeiten, wie ein container durch Berechtigungen angreifbar werden container . Dies gilt insbesondere bei der Verwendung eines container wie Kubernetes, der Container automatisch erstellt, ändert und löscht. 

Mit CVE-2023-2640 und CVE-2023-32629 kann ein Angreifer einen container ohne Root-Rechte container Volume-Mount verwenden, um seine Rechte zu erweitern. 

In Kubernetes würden Sie den Sicherheitskontext verwenden, um Berechtigungen und Zugriffskontrolleinstellungen für einen container zu definieren.

Im oben genannten Sicherheitskontext: 

• runAsNonRoot: true: Stellt sicher, dass container als UID 0 gestartet wird.
• runAsUser: 1000: Führt den container explizit container Nicht-Root-Benutzer aus.
• allowPrivilegeEscalation: false: Blockiert setuid oder andere Eskalationen
• capabilities.drop: [ALL]: Entfernt standardmäßig alle Linux-Fähigkeiten.

Die Verwaltung container und -Zugriffen erfordert ein Verständnis dafür, wie sich Ihre Anwendung verhält. Wenn Sie beispielsweise keine Schreibvorgänge auf die Festplatte durchführen, sollten Sie alle zugehörigen Volumes als schreibgeschützt mounten, um die Angriffsfläche weiter zu verringern.

Lesen Sie unseren Leitfaden zu Sicherheitslücken bei der Erweiterung von container und wie Sie sich davor schützen können.

Schweregrad: Hoch → Kritisch

9. gh0stEdit: Layer-basierte Zugriffsschwachstelle

Docker-Images sind so konzipiert, dass Endbenutzer den Inhalt eines Images vor dessen Ausführung klar beurteilen und einsehen können. 

Im Fall von gh0stEdit spielt diese Sichtbarkeit jedoch keine Rolle. 

Obwohl es sich nicht um eine formelle CVE handelt, beschreibt gh0stEdit (Name von den Forschern vergeben) eine neuartige Schwachstelle, bei der ein Angreifer Docker-Images (selbst solche, die mit Docker Content Trust signiert sind) manipulieren kann, ohne die Image-Signatur zu beschädigen oder von statischen/dynamischen Scans erkannt zu werden. 

Abbildung 1: Umgehung der Docker-Image-Integrität: Layer geändert, Manifest unverändert. Quelle (Hackernoon)‍

Diese Manipulation ist möglich, weil Docker sich auf das Manifest konzentriert (das Rezept, das die Image-Layer und ihre Digests auflistet) und nicht auf jede einzelne Datei innerhalb jedes Layers. 

Wenn ein Angreifer ein bösartiges Skript in eine Ebene einschleust, container der container , wobei die Dockerfile-, Build-Prozess- und Registrierungsprüfungen umgangen werden. Es kann sich unbemerkt in Ihrem gesamten System verbreiten. 

Die Behebung und Abwehr von gh0stEdit umfasst mehrere Schritte, darunter:

• container immer aus vertrauenswürdigen Quellen neu erstellen
• Signieren und Verifizieren von container mit Tools wie cosign
• Schwachstellen- und Inhaltsscans mit Tools wie Aikido ergänzt Open-Source-Scanner durch benutzerdefinierte Regeln, schließt Lücken und deckt Sicherheitslücken auf. 
• Verwenden Sie einen Zulassungscontroller, um zu verhindern, dass nicht signierte oder nicht gescannte Images in Ihrem Cluster ausgeführt werden.

Schweregrad: Niedrig → Kritisch (abhängig von den container und der Angriffsfläche)

Aufbau einer widerstandsfähigen Docker-Sicherheitsstrategie

Wie wir in diesem Artikel untersucht haben, können Schwachstellen wie container , nicht gescannte Basisimages, offengelegte secrets und übermäßige Berechtigungen Ihre gesamte Umgebung unbemerkt untergraben. 

Die Implementierung einer robusten Docker-Sicherheitsstrategie bedeutet, über einfache Checkbox-Scans hinauszugehen und kontextbezogene, laufzeitbewusste, richtliniengesteuerte Abwehrmaßnahmen zu implementieren, die Schwachstellen automatisch finden und beheben. 

Bei Aikido lieben wir etablierte Open-Source-Projekte wie Trivy, Syft und Grype. Aber wir wissen auch aus Erfahrung, dass ihre isolierte Verwendung keine besonders gute Entwicklererfahrung ist. 

Aikido diese Projekte um benutzerdefinierte 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 Aikido Sie Aikido davon, ein Scan-Skript erstellen oder einen benutzerdefinierten Job in Ihrer CI/CD erstellen zu müssen.

Es gibt immer mehr über die Sicherheit von Docker zu lernen. Um weitere Fragen zur Sicherheit von Docker zu beantworten, lesen Sie unsere No-BS-Sicherheitscheckliste für Docker für Entwickler, die sich mit Schwachstellen auskennen.