Docker Podman Security: Rootless-Härtung und 5 kritische CVEs aus 2025

Seit Anfang 2025 rollt eine Serie konkreter CVEs durch den Container-Runtime-Stack: Rootless-Escapes, TLS-Validierungslücken und Build-Zeit-Angriffe zeigen, dass „Container laufen“ und „Container laufen sicher“ zwei verschiedene Betriebszustände sind. Wer Podman oder Docker auf Produktionssystemen oder im Homelab betreibt, sollte wissen, welche Patches jetzt wirklich wichtig sind – und warum Image-Scanning allein nicht reicht.

Was im Juni 2025 konkret gepatcht wurde

Der Container-Security-Stack ist kein monolithisches Produkt. Podman, Docker Engine, runc, BuildKit und die jeweiligen Distro-Pakete entwickeln sich parallel weiter – und werden auch separat gepflegt. Das macht Upgrade-Strategien komplizierter, als es auf den ersten Blick aussieht.

Für Podman listet das offizielle GitHub Security Advisory aktuell mehrere relevante CVEs aus dem ersten Halbjahr 2025. Drei davon sind besonders wichtig für Produktionsumgebungen: CVE-2025-52881 erlaubt über „arbitrary write gadgets and procfs write redirects“ einen runc-Container-Escape kombiniert mit Denial of Service. CVE-2025-9566 betrifft `podman play kube` – über manipulierte Symlinks in ConfigMap- und Secret-Volumes konnten Host-Dateien überschrieben werden. Und CVE-2025-6032 beschreibt eine fehlende TLS-Zertifikatsprüfung beim Download von VM-Images in `podman machine init`, was Man-in-the-Middle-Angriffe bei der Image-Provisionierung ermöglicht.

Red Hat veröffentlichte am 13. Mai 2025 das Advisory RHSA-2025:7462 mit dem Severity-Level „Important“. Es adressiert unter anderem einen DoS in `golang.org/x/crypto/ssh` (CVE-2025-22869) und Go-JOSE-Parsing-Issues (CVE-2025-27144). Oracle Linux folgte mit ELSA-2025-7391 am 21. Mai und ELSA-2025-9144 am 17. Juni, letzteres wegen CVE-2025-22871 (HTTP Request Smuggling in `net/http` durch invaliden chunked Traffic).

Fedora hat über Advisory FEDORA-2025-d6689393a3 ein automatisches Update auf podman-5.5.2-1.fc42 ausgerollt, das CVE-2025-6032 schließt. Wer auf Fedora 42 unterwegs ist, bekommt das ohne manuellen Eingriff – vorausgesetzt, automatische Updates sind aktiviert oder `dnf upgrade podman` wurde ausgeführt.

Docker Desktop und BuildKit: Der runc-Fixstatus

Docker Desktop-Nutzer sollten ihren Versionsstand ebenfalls prüfen. Die Docker Security Announcements dokumentieren, dass Versionen bis einschließlich Desktop v4.27.0 von runc- und BuildKit-CVEs betroffen waren. Version 4.27.1 (veröffentlicht am 1. Februar 2024) enthält die entsprechenden Patches für runc, BuildKit und dockerd. Alle nachfolgenden Releases bauen darauf auf.

Wer Docker Engine auf einem Linux-Server ohne Desktop-Komponente betreibt, bekommt runc-Updates über die normale Paketverwaltung. Wichtig: Das Docker-Paket in den offiziellen Distro-Repositories und das Paket aus dem Docker-eigenen Repository (`apt.docker.io` oder `download.docker.com`) liefern teils unterschiedliche Versionsstände. Gerade auf Ubuntu LTS oder Debian Stable kann der Distro-eigene Build mehrere Monate hinter dem upstream Docker-Release zurückliegen. Wer Security-Patches zeitnah braucht, sollte das Docker-eigene Repository einbinden.

Für docker compose und docker build gilt: BuildKit ist seit Docker Engine 23.x standardmäßig aktiv. Die Build-Zeit-CVE CVE-2024-1753 (Container-Escape über manipuliertes Containerfile) betrifft genau diesen Pfad. Ein Upgrade auf eine aktuell gepatchte Engine-Version ist in jedem Build-Kontext Pflicht – nicht optional.

Rootless-Modus: Was er leisten kann und wo er versagt

Rootless-Container sind kein Silver Bullet. Das zeigen die aktuellen CVEs sehr deutlich. Der Kernvorteil ist real: Wenn ein Container-Prozess im Rootless-Modus läuft, hat er auf dem Host keine Root-Rechte. Ein erfolgreicher Container-Escape landet damit in einem unprivilegierten User-Namespace statt direkt als UID 0 auf dem Host. Das ist eine substanzielle Reduktion der Schadenswirkung.

Allerdings zeigen CVE-2024-1753 (Container-Escape zur Build-Zeit über böswilliges Containerfile) und CVE-2025-9566 (Host-File-Overwrite über `podman play kube`), dass Fehlkonfigurationen auch im Rootless-Betrieb fatale Folgen haben können. Der klassische Fehler: weitreichende Host-Mounts ins Container-Setup zu ziehen. Wer `$HOME` oder `/var/lib/containers` als Volume einhängt, hebelt den Rootless-Vorteil effektiv aus. Dasselbe gilt für den Docker-Socket – wird `/var/run/docker.sock` ins Container-Image gemountet, ist eine Privilege-Escalation auf Root-Niveau trivial.

Die SUSE-Security-Advisories SUSE-SU-2025:20279-1 und SUSE-SU-2025:3782-1 liefern einen weiteren Hinweis. CVE-2024-9407 betrifft `RUN –mount` (bind-propagation) in Dockerfiles und erlaubt unerwartete Host-Interaktionen. Die Botschaft dahinter: Die Build-Pipeline ist ein gleichwertiger Angriffspfad wie die Runtime, und Rootless-Modus schützt dort nicht automatisch.

Capabilities korrekt konfigurieren

Ein älterer, aber weiterhin relevanter Designpunkt aus dem Podman-Security-Advisory GHSA-qvf8-p83w-v58j: Inheritable Capabilities in Linux-Containern sollten standardmäßig leer sein. Im Rootless-Modus werden Capabilities anders gehandhabt als im privilegierten Betrieb, was Raum für Konfigurationsfehler lässt. Konkret bedeutet das: `–cap-drop=ALL` beim Container-Start setzen und nur explizit benötigte Capabilities per `–cap-add` hinzufügen. Wer nextcloud docker, postgres docker oder redis docker im Homelab betreibt, braucht für diese Workloads in der Regel keine erhöhten Capabilities – die Standardprofile reichen.

Meine persönliche Einschätzung: Die Diskussion „Podman ist sicherer als Docker“ greift zu kurz. Beide Runtime-Stacks teilen runc als Unterbau, beide wurden 2024/2025 von vergleichbaren CVE-Klassen erwischt. Der strukturelle Vorteil von Podman liegt im daemonlosen Betrieb und der nativen Rootless-Unterstützung – aber CVE-2025-6032 (TLS-Bug in `podman machine init`) zeigt, dass die Angriffsfläche sich nur verschiebt, nicht verschwindet.

User-Namespace-Mapping als zusätzliche Schutzschicht

Ein Aspekt, der in der Rootless-Diskussion oft untergeht, ist das konkrete UID-Mapping. Im Rootless-Betrieb werden Container-UIDs auf einen subordianten Bereich des Host-Nutzers gemappt – typischerweise via `/etc/subuid` und `/etc/subgid`. Prozesse, die innerhalb des Containers als UID 0 laufen, erscheinen auf dem Host als eine UID weit außerhalb des privilegierten Bereichs, etwa UID 100000. Das ist technisch wichtig: Selbst wenn ein Angreifer einen Container-Escape erreicht, landet er nicht als Root, sondern als ein unprivilegierter Nutzer ohne Shell-Zugang zu systemkritischen Dateien.

In der Praxis scheitert dieser Mechanismus jedoch häufig an Konfigurationsfehlern. Wer `–userns=host` im `containers.conf` oder direkt beim Podman-Start setzt, deaktiviert das Namespace-Mapping vollständig. Ähnliches gilt für `–privileged`-Container: Sie erhalten explizit alle Capabilities zurück und umgehen die Namespace-Isolation. Für Produktionsumgebungen gilt daher die Faustregel, privilegierte Container nur dort einzusetzen, wo es technisch zwingend notwendig ist – beispielsweise bei bestimmten Netzwerk- oder Storage-Plugins – und den Einsatz im Code-Review-Prozess zu dokumentieren und zu begründen.

Supply-Chain-Verification: Das unterschätzte Risiko

Das GitHub Security Advisory GHSA-34xh-hvp7-r2j7 beschreibt eine Supply-Chain-Schwachstelle im `machine-os` GitHub Actions Workflow von Podman. Das ist keine Schwachstelle in der Container-Runtime selbst, sondern in der Build-Pipeline, die Podman-Images produziert. Genau diese Kategorie wird bei Image-Scans systematisch übersehen.

Image-Scanner wie Trivy, Grype oder Snyk arbeiten gegen bekannte CVE-Datenbanken in den Image-Layers. Sie erkennen, ob eine bestimmte Library-Version eine bekannte Schwachstelle hat. Was sie nicht erkennen: Manipulierte Build-Umgebungen, kompromittierte Upstream-Images auf Docker Hub, oder Runtime-Probleme in der Container-Engine selbst. Die TLS-Validierungslücke CVE-2025-6032 in `podman machine` ist ein Paradebeispiel dafür – ein Scanner würde das Image als „clean“ bewerten, das eigentliche Problem liegt in der VM-Provisioning-Logik.

Für Self-Hosting-Setups und Kubernetes-Umgebungen bedeutet das: Image-Scanning ist notwendig, aber nicht hinreichend. Sinnvoll ergänzen lässt sich das durch Signaturen (Cosign/Sigstore), SBOM-Validierung und das konsequente Pinnen auf spezifische Image-Digests statt Tags. `latest` als Image-Tag ist in Produktionsumgebungen generell eine schlechte Idee – nicht weil es immer zu Problemen führt, sondern weil Reproduzierbarkeit und Auditierbarkeit fehlen.

Watchtower und automatische Image-Updates

Watchtower docker ist in Self-Hosting-Kreisen beliebt, weil es Container automatisch aktualisiert, wenn neue Image-Versionen verfügbar sind. Das klingt nach einer einfachen Lösung für das Update-Problem, hat aber eine Kehrseite: Watchtower übernimmt unkritisch jedes neue Image-Tag – ohne Signaturprüfung, ohne SBOM-Vergleich. Wer ein Docker-Hub-Image verwendet, das ohne Content Trust ausgeliefert wird, nimmt jedes Update als Trust-by-default an. In Kombination mit den Supply-Chain-Risiken aus dem Podman-Advisory ist das eine Abwägung, die jeder Administrator bewusst treffen sollte.

Private Registries als Kontrollpunkt

Eine praxisnahe Gegenmaßnahme zum unkontrollierten Docker-Hub-Pull ist das Vorschalten einer privaten Registry. Lösungen wie Harbor oder Gitea-integrierte Container-Registries erlauben es, eingehende Images zu scannen, mit eigenen Signaturen zu versehen und in einem internen Namespace zu spiegeln. Container-Deployments beziehen ihre Images dann ausschließlich aus der internen Registry – öffentliche Registries sind aus der Produktionsumgebung netzwerkseitig nicht erreichbar. Das schränkt die Angriffsfläche für Supply-Chain-Angriffe erheblich ein, erfordert aber initialen Konfigurationsaufwand und eine Strategie für regelmäßige Upstream-Synchronisation. Gerade in Teams, die mehrere docker-compose-Stacks parallel betreiben, ist dieser Aufwand langfristig durch reduzierte Incident-Kosten gerechtfertigt. Wer KI-gestützte Entwicklungswerkzeuge und automatisch generierte Container-Konfigurationen in seine Pipeline integriert, sollte diesen Kontrollpunkt besonders konsequent einplanen, da generierte Dockerfiles häufig auf unpinnte Base-Images und öffentliche Abhängigkeiten setzen.

Upgrade-Anleitung: Konkrete Schritte für Admins

Der Upgrade-Pfad hängt stark von der Distribution und dem Deployment-Modell ab. Hier die relevanten Schritte je nach Stack:

Fedora / RHEL-basierte Systeme: `dnf upgrade podman` oder auf RHEL über den Errata-Kanal das Advisory RHSA-2025:7462 einspielen. Ziel ist Podman ≥ 5.5.2 auf Fedora 42 beziehungsweise das aktuelle Backport-Paket mit den CVE-Fixes auf RHEL 9.x. Nach dem Upgrade lohnt sich ein Blick in `rpm -q –changelog podman | head -50`, um die eingebetteten CVE-Fixes zu verifizieren.

SUSE / openSUSE: Die Advisories SUSE-SU-2025:20279-1, SUSE-SU-2025:20805-1 und SUSE-SU-2025:3782-1 über `zypper patch` einspielen. SUSE liefert die Fixes als Vendor-Backports, die genaue Versionsnummer unterscheidet sich daher von den upstream 5.x-Releases.

Debian / Ubuntu: Wer Podman aus den Distro-Repositories bezieht, muss den Backports-Stand prüfen. Für Docker Engine: Das offizielle Docker-Repository (`download.docker.com`) ist die zuverlässigere Quelle für zeitnahe Security-Patches. `apt update && apt upgrade docker-ce docker-ce-cli containerd.io` aktualisiert den Stack.

Kubernetes-Umgebungen mit CRI-O oder containerd: Hier ist runc das primäre Update-Ziel. `containerd` und `runc` werden als separate Pakete gepflegt – ein Upgrade auf `containerd ≥ 1.7.x` mit dem aktuellen runc-Binary schließt die bekannten Escape-CVEs. Wer kubeadm einsetzt, sollte nach dem Node-Upgrade `crictl info` ausführen und die Runtime-Version verifizieren.

Docker Desktop (macOS/Windows): Über das eingebaute Update-System auf die aktuelle Version aktualisieren. Jede Version jenseits von 4.27.1 enthält die runc/BuildKit-Fixes aus dem Februar-2024-Advisory. Der Stand lässt sich unter „Docker Desktop > About Docker Desktop“ überprüfen.

Seccomp, AppArmor und SELinux: Die zweite Verteidigungslinie

Patches allein sind keine vollständige Strategie. Runtime-Policies bilden die zweite Verteidigungslinie, die greift, wenn eine Zero-Day-Lücke ausgenutzt wird oder ein Patch noch nicht ausgerollt ist. Podman und Docker bringen beide Standard-Seccomp-Profile mit, die eine erhebliche Anzahl von Syscalls sperren. Diese Profile sind per Default aktiv – solange man sie nicht explizit mit `–security-opt seccomp=unconfined` deaktiviert.

Auf SELinux-Systemen (RHEL, Fedora, CentOS Stream) läuft Podman mit den vordefinierten `container_t`-Policies. Diese begrenzen, welche Host-Ressourcen ein Container-Prozess überhaupt ansprechen kann, unabhängig davon, ob er Root-Rechte hat oder nicht. CVE-2025-9566 (Host-File-Overwrite über Symlinks in `podman play kube`) wäre auf korrekt konfigurierten SELinux-Systemen deutlich schwerer auszunutzen gewesen.

AppArmor übernimmt diese Rolle auf Debian/Ubuntu-Systemen. Docker generiert beim Container-Start automatisch ein AppArmor-Profil (`docker-default`), das grundlegende Einschränkungen durchsetzt. Wer Produktions-Container betreibt, sollte prüfen, ob anwendungsspezifische Profile sinnvoll sind – gerade für Dienste wie nextcloud docker oder postgres docker, deren Zugriffsmuster vorhersehbar und gut eingrenzbar sind.

Ich halte das konsequente Aktivhalten von Mandatory Access Controls für mindestens genauso wichtig wie regelmäßige Patches. Schatten-IT-Setups im Homelab, die Container ohne jede Policy-Absicherung betreiben, sind ein eigenes Risikoprofil – besonders wenn sie öffentlich erreichbare Dienste hosten.

Monitoring und Incident Detection im Container-Kontext

Wer Container-Sicherheit ernst nimmt, sollte neben präventiven Maßnahmen auch detektive Kontrollen einplanen. Im Container-Kontext bedeutet das konkret: unerwartete Syscall-Muster erkennen, bevor ein Angriff eskaliert. Tools wie Falco (CNCF-Projekt) erlauben es, zur Laufzeit Regeln zu definieren, die auf verdächtige Aktivitäten reagieren – etwa wenn ein Container-Prozess versucht, auf `/proc/self/exe` schreibend zuzugreifen, oder wenn ein Kindprozess außerhalb des erwarteten Prozessbaums spawnt.

Für kleinere Setups, die keinen vollständigen Falco-Stack betreiben möchten, bietet schon das sorgfältige Auswerten der Container-Logs mit strukturiertem Logging (JSON-Format, zentrales Log-Aggregat) eine Grundlage, um Anomalien nachträglich zu rekonstruieren. Beim Einsatz von Zwei-Faktor-Authentifizierung für den Zugang zur Container-Management-Oberfläche – ob Portainer, Cockpit oder direktes SSH – sinkt das Risiko eines unbefugten Eingriffs in laufende Container erheblich, auch wenn die Runtime selbst eine ungepatchte Schwachstelle enthält.

Ein weiterer praxisrelevanter Punkt: Read-only-Filesysteme für Container, die keine persistenten Schreiboperationen benötigen. Mit `–read-only` und gezielten `tmpfs`-Mounts für Verzeichnisse wie `/tmp` oder `/run` wird der Angriffsraum für Exploit-Payloads, die Schreibzugriff auf das Dateisystem voraussetzen, substanziell eingeschränkt. Die meisten Webserver- und Proxy-Container (nginx, traefik, caddy) laufen problemlos im Read-only-Modus.

Was bleibt, und was sollten Sie jetzt tun?

Die CVE-Welle aus dem ersten Halbjahr 2025 zeigt ein wiederkehrendes Muster: Container-Escapes entstehen nicht nur durch kaputte Images, sondern durch Schwachstellen in der Build-Toolchain, in Orchestrierungskomponenten (`podman play kube`) und in der VM-Provisioning-Logik. Rootless-Betrieb reduziert die Schadenswirkung eines erfolgreichen Angriffs, ersetzt aber keine anderen Härtungsmaßnahmen.

Die unmittelbaren Handlungsschritte: Podman auf den Versionsstand ≥ 5.5.x bringen (respektive das aktuelle Distro-Errata einspielen), Docker Desktop auf eine Version jenseits von 4.27.1 aktualisieren, runc über die Paketverwaltung auf den neuesten Stand heben. Danach: Volume-Mounts auditieren, `–cap-drop=ALL` als Standard etablieren, Seccomp- und SELinux/AppArmor-Policies aktiv lassen.

Die grundsätzlichere Frage bleibt offen: Wie viele Self-Hosting-Setups betreiben Container im Produktivbetrieb, ohne jemals einen systematischen Blick auf die Runtime-CVE-Historie geworfen zu haben? Docker Hub hat eine enorme Nutzerbasis – aber wie viele der dort bezogenen Images wurden gegen aktuelle Schwachstellen gescannt, signiert und auf einen bekannten Digest gepinnt? Das ist keine rhetorische Übung, sondern eine Frage, die jeden Betreiber eines docker compose-Stacks direkt betrifft.