Podman 6.2 und 5.8.10: Präparierte Images umgehen Signaturprüfung und Auto-Update

Das Podman-Projekt hat am 10. November 2026 Podman 6.2.0 und für die ältere Reihe Podman 5.8.10 veröffentlicht. Beide Versionen schließen drei Sicherheitslücken: Präparierte Images können die automatische Aktualisierung dazu bringen, falsche systemd-Units neu zu starten, und die Prüfung von Digest und Signatur umgehen. Ein bösartiger Container kann zudem eine Sperre im Standard-Seccomp-Profil aushebeln.

Betroffen sind vor allem Hosts, die Images aus nicht vollständig vertrauenswürdigen Quellen ziehen oder podman auto-update nutzen. Wer nur eigene, geprüfte Images einsetzt, hat ein geringeres Risiko. Das Update gehört trotzdem ins nächste reguläre Wartungsfenster.

Was ist passiert?

Die Release-Notes zu 6.2.0 nennen drei CVEs:

• CVE-2026-121885 (CVSS 6.5): Podman übernimmt beim Start eines Containers alle Labels des Images. Ein Angreifer kann deshalb Images mit Auto-Update-Labels bauen und podman auto-update dazu bringen, beliebige systemd-Units als der Podman-Benutzer neu zu starten. Läuft Podman als root, kann das laut Advisory im schlimmsten Fall den ganzen Host ausfallen lassen, nämlich wenn so poweroff.target erreicht wird.
• CVE-2026-111361 (CVSS 4.6): Ein bösartiges Image kann so gebaut werden, dass es zum Digest eines anderen Images passt, aber andere Layer und Konfiguration enthält. Damit lassen sich Digest-Referenzen und Signaturen umgehen. Die Lücke steckt in der Bibliothek container-libs (go.podman.io/image).
• CVE-2026-123876: Ein bösartiger Container konnte eine Socket-Sperrregel im Standard-Seccomp-Profil umgehen. Ein Advisory oder eine CVSS-Bewertung nennen die Release-Notes dazu nicht.

Daneben bringt Podman 6.2 neue Optionen für podman kube play, den Quadlet-Schlüssel Umask für Container-Dateien und SetMountsDependency für alle Quadlet-Dateien, native systemd-Unterstützung für Podman-Maschinen unter WSL (setzt jetzt mindestens WSL 2.5.1 voraus) und einen Filter für podman auto-update.

Wer ist betroffen?

• CVE-2026-121885: Podman ab 1.8.2 bis vor 6.2.0, in der 5er-Reihe bis vor 5.8.10.
• CVE-2026-111361: go.podman.io/image/v5 von 5.40.0 bis vor 5.42.1 und vor 5.39.4. Für das alte Modul github.com/containers/image/v5 gibt es keinen Fix, Projekte sollen auf go.podman.io/image/v5 umsteigen.
• Für CVE-2026-123876 nennen die Quellen keinen Versionsbereich. Podman 6.2.0 und 5.8.10 enthalten alle drei Korrekturen.

Wer Podman aus Distributionspaketen nutzt, bekommt die Fixes erst mit den Updates der jeweiligen Distribution. Ob und wann sie zurückportiert werden, hängt vom Anbieter ab.

Wie kritisch ist das?

Hinweise auf laufende Angriffe nennen die Quellen nicht, und alle Lücken setzen ein präpariertes Image oder einen bösartigen Container auf dem Host voraus. Die Auto-Update-Lücke betrifft Hosts, auf denen podman auto-update läuft, etwa per Timer, auch wenn der betroffene Container selbst gar nicht für Auto-Update gedacht war. Die Signatur-Umgehung ist dort relevant, wo Admins sich auf signierte Images oder feste Digests als Schutz verlassen. Die Seccomp-Lücke lässt sich mangels Details noch nicht genau einordnen.

Was sollten Admins jetzt tun?

• Version prüfen: podman version auf allen Hosts ausführen und auf 6.2.0 oder 5.8.10 aktualisieren, sobald die Pakete der Distribution bereitstehen.
• Bis dahin podman auto-update nur für Container aus vertrauenswürdigen Quellen nutzen. Das Advisory empfiehlt, die Labels vor dem Start zu prüfen: podman image inspect --format '{{.Config.Labels}}' IMAGE, dabei dürfen die Labels io.containers.autoupdate und PODMAN_SYSTEMD_UNIT im Image nicht gesetzt sein.
• Bei bestehenden Containern die Labels kontrollieren und sicherstellen, dass die Auto-Update-Labels nur so gesetzt sind, wie es die eigene Konfiguration vorsieht.
• Eigene Go-Projekte, die container-libs nutzen, auf go.podman.io/image/v5 5.42.1 oder 5.39.4 heben. Wer noch github.com/containers/image/v5 nutzt, muss auf go.podman.io/image/v5 umsteigen.

Einordnung für Unternehmen

Podman ist auf Red-Hat-nahen Systemen und Fedora oft der Standard für Container, mit Quadlet auch auf Servern ohne Docker. Eigene Einschätzung: Für die meisten kleinen Umgebungen ist das kein Notfall, aber ein Anlass, die Herkunft der genutzten Images und die Auto-Update-Regeln zu prüfen. Wer Images aus öffentlichen Registries automatisch aktualisiert, sollte das Update vorziehen.

Passende Anleitungen auf S-EDV

• Docker-Container automatisch aktualisieren nach dem Watchtower-Aus: Diun, WUD und Renovate im Vergleich
• Docker Rootless Mode auf Debian und Ubuntu einrichten

Quellen

• Podman: Release-Notes zu 6.2.0
• Podman: Release-Notes zu 5.8.10
• GitHub: Advisory zu CVE-2026-121885
• GitHub: Advisory zu CVE-2026-111361
• Linuxiac: Bericht zu Podman 6.2