Podman-CVE-2026-94603: Eine Image-Annotation schaltet die Sandbox ab

Die Podman-Maintainer haben am 29. September 2026 in den Versionen 5.8.8 und 6.1.3 eine Funktion entfernt, statt sie zu patchen. Dahinter liegt CVE-2026-94603: podman run akzeptierte jedes Image, das eine bestimmte Annotation mitbringt, als Checkpoint und stellte den Container mit den Sicherheitswerten des Images her. Die Einschränkungen, die der Betreiber auf der Kommandozeile gesetzt hatte, galten dann nicht mehr. Die öffentliche Advisory des Projekts kam am 15. Oktober 2026, mit CVSS 10.0.

Der Fehler ist nicht neu. Die Funktion wurde mit Podman 4.4.0 eingeführt, veröffentlicht am 1. Februar 2023. Von dort bis 5.8.7 und bis 6.1.2 ist jede Fassung betroffen, die das Projekt selbst in seiner Advisory nennt.

Was beim podman run passiert

Seit 4.4.0 ließ sich ein mit podman container checkpoint erzeugter Zustand als Image in eine Registry legen und auf einer anderen Maschine wieder ausführen. Für die Übertragung zwischen Systemen ist das praktisch, und genau dort sitzt das Problem. Die Erkennung läuft über eine einzige Image-Annotation, io.podman.annotations.checkpoint.runtime.name. Ist sie gesetzt, behandelt podman run das Image als Checkpoint.

Der Revert-Commit vom 28. September 2026 (Autor Matt Heon) zeigt die Stelle im Quelltext. Im Run-Pfad wird geprüft, ob die Annotation im Image steht, und wenn ja, ruft Podman intern ContainerRestore auf, bevor irgendwelche Nutzeroptionen verarbeitet werden. Der Kommentar im Commit ist deutlich: This commit has been identified as a serious security issue. Ein --cap-drop=ALL auf einem Checkpoint-Image wird ignoriert, die Capability-Menge kommt aus dem Image. Das Advisory nennt als Folge schwächere Sandbox-Einstellungen und Capabilities nach Wahl des Images.

Rootless-Container sind nach Angabe des Projekts nicht betroffen, weil Checkpoint und Restore in diesem Modus gar nicht unterstützt werden. Das ist die einzige gute Nachricht an der Stelle, und sie ist immerhin eine strukturelle.

Zwei Bewertungen, zwei Vektoren

Der Maintainer und Red Hat kommen auf verschiedene Zahlen, und der Unterschied lohnt sich anzusehen, weil er die eigene Priorität erklärt.

Die CVE-Datenführung über die CNA GitHub (veröffentlicht am 13.10.2026, CWE-693 Protection Mechanism Failure) trägt CVSS 3.1 mit 10.0 und dem Vektor AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Dieselbe Lücke führt Red Hat mit 8.6 und dem Vektor CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, eingestuft als Important und als CWE-15, mit public date 29.09.2026. Ubuntu nennt auf seiner CVE-Seite die 10.0 des Maintainers als cvss3, setzt die eigene Priorität aber auf medium. Die NVD führte am 16. Oktober noch keinen eigenen Datensatz zu der CVE (Anfrage gegen die NVD-Schnittstelle: HTTP 404).

Der Streitpunkt steckt in zwei Feldern: AV:N gegen AV:L und UI:N gegen UI:R. Der Maintainer rechnet mit einem Angreifer, der ein Image in eine Pipeline bringt, ohne selbst auf dem Zielsystem zu sitzen. Red Hat zählt den Menschen oder den Automatisierungsjob, der das Image startet, als notwendige Bedingung und schreibt die Bedingung ausdrücklich dazu: Ausnutzung verlangt, dass ein Betreiber oder ein Workflow ein ungeprüftes Image startet; Umgebungen, die nur gesichtete Images aus vertrauenswürdigen Registries ausführen, bleiben mit reduziertem Risiko. Auf die Frage, ob eine Gegenmaßnahme existiert, antwortet Red Hat mit einem klaren Nein: keine verfügbare, die ihre Kriterien erfüllt.

Beide Zahlen sind Primärangaben, keine davon ist eine Messung. Wer für seine Firma entscheidet, kann die Differenz direkt übersetzen: Stehen CI-Läufe oder Selbstbedienungsumgebungen, in denen jemand ein fremdes Image startet, dann liegt die Wirkung näher an der 10.0. Läuft nur der eigene Build aus der eigenen Registry, ist Red Hats Lesart die realistischere.

Was die Distributoren geliefert haben

Upstream ist die Sache seit dem 29. September erledigt, die aktuellen Zweige sind 5.8.9 und 6.1.4 (beide 12.10.2026). In den Betrieben liegt der Stand weiter zurück. Die folgende Tabelle haben wir am 16. Oktober bei den Distributoren direkt gelesen.

Debian führt trixie im Security-Tracker als verwundbar, gefixt ist der Stand nur in sid. Wer Debian 13 im Server betreibt, hängt also an einem Zweig, der nicht gepatcht wird. Red Hat listet podman auf RHEL 8, 9 und 10 sowie auf OpenShift 4 als Affected; die vorhandenen Meldungen betreffen die Hardened Images und Quay. Bei Fedora stehen die Aktualisierungen seit dem 13. und 14. Oktober im Testing. SUSE war aus diesem Container nicht erreichbar (HTTP 000, auch mit Browser-User-Agent), dazu sagen wir nichts.

Der Blick in unsere eigene Flotte

Der Kandidat der Paketverwaltung entscheidet, was ein apt install podman oder ein Update auf einem unserer Hosts tatsächlich liefern würde. Ubuntu 24.04 brächte 4.9.3, Ubuntu 26.04 brächte 5.7.0, Debian 13 brächte 5.4.2. Alle drei liegen innerhalb der betroffenen Spanne. Auf dem geprüften Alpine-3.23-Host lieferte das Repo-Verzeichnis keine Zeile für podman, dazu messen wir nicht weiter nach.

Nachspielen konnten wir den Fehler nicht. Es gibt in unserem Bestand kein Podman und auf dem geprüften Host auch kein skopeo, wir hätten also erst eine verwundbare Umgebung bauen müssen. Der Mechanismus stammt deshalb im ganzen Beitrag aus dem Quelltext und dem Advisory, unser Beitrag ist die Einordnung für den Betrieb. Docker auf unseren 20 Hosts ist nach den Quellen nicht betroffen: Die fehlerhafte Weiche steht im Run-Pfad von Podman, und der Fix ist ein Revert in diesem Zweig.

Unser Quellenpool nannte diese CVE beim nächtlichen Lauf um 05:45 genau einmal, nämlich die GitHub-Advisory selbst. Von 324 aktiven Quellen hatten 309 funktioniert, zehn sammeln seit mindestens zwei Wochen Fehler.

Was weitere Quellen sagen

Amazon Linux führt die CVE in seiner Datenbank mit CVSS 8.6, also wie Red Hat und nicht wie der Maintainer. Sicherheitsportale wie securityonline und thehackerwire haben die Meldung wiederholt, ihre Texte nennen teils andere Spannen oder Zahlen als das Advisory, und wir haben sie deshalb nicht als Quelle benutzt. Eine Diskussion in Foren haben wir gesucht (Hacker News, Stand 16.10.2026) und zu dieser CVE nicht gefunden. Das einzige Podman-Thema der Woche dort war die Vorstellung eines Deploy-Werkzeugs für Docker und Podman. Wer die Frage in der Praxis diskutieren will, findet sie im Advisory des Projekts.

Was Betreiber jetzt prüfen

podman --version zuerst. Betroffen sind laut Advisory die Spannen 4.4.0 bis unter 5.8.8 und 6.0.0 bis unter 6.1.3. Ein Rootless-Betrieb ist nach der Aussage des Projekts gegen genau diesen Weg gefeit, weil es dort kein Checkpoint und keinen Restore gibt; auf Servern, deren Distro-Paket noch hängt, ist das der Hebel, der heute wirkt, sofern die Anwendung mitmacht.

Die zweite Zeile ist die Frage, wer die Images baut. Ein Image aus einer Registry ist ein Programm, das wir starten, und hier bringt es sogar die Sandbox-Parameter mit. Wer CI-Läufe mit Images aus Pull-Requests fährt, sollte diese Lücke als weiteren Grund nehmen, fremde Images in einer eigenen, streng gekapselten Stufe zu behandeln; unser Muster dafür steht in Vier Dateien vor der Installation.

Die dritte Zeile ist der Prüfschritt selbst. Podman prüft die Annotation nicht von allein, das Advisory sagt das ausdrücklich, also bleibt nur ein Scan vor dem Start. Das Feld heißt Annotations und ist im Inspect-Auswurf des Projekts enthalten, belegt über den Quelltext und den zugehörigen e2e-Test der Version 5.8.7:

podman image inspect --format '{{ json .Annotations }}' <image> \
  | grep -c io.podman.annotations.checkpoint

Ein Treffer heißt: Image ablehnen. Registry-seitig, also vor dem Pull, braucht es denselben Scan als Policy. Die nimmt uns kein Distributor ab.

Bleibt das Update. Upstream ist es seit zweieinhalb Wochen draußen, bei Debian stable und RHEL liegt es weiter nicht im Paket. Wer dort nicht auf Rootless umstellen kann, bleibt bis auf Weiteres an einer eigenen Übersetzung aus dem Quelltext hängen. Unbequem, und die ehrliche Antwort auf die Frage, was eine CVSS-10.0 kostet, wenn der Distributor sie noch nicht ausliefert.

So haben wir gemessen

Am 16. Oktober 2026 haben wir 30 Hosts per ssh angefragt, 21 antworteten. Je Host haben wir hostname und podman --version gelesen, den Kandidaten der Paketverwaltung über apt-cache policy podman beziehungsweise die Alpine-Paketsuche und die laufenden Container über docker ps. Podman war auf keinem erreichten Host installiert, auf 20 der 21 lief Docker mit zusammen 133 Containern. Die Tabelle der Distributoren stammt aus deren Datenbanken vom selben Tag, Bodhi (Fedora) steht hinter einem Bot-Schutz und lässt sich nur im Browser öffnen. Die Annotations-Prüfung haben wir nicht an einem verwundbaren System nachgespielt, weil keines vorhanden ist.

Weiterführende Quellen

Primärquellen

• Advisory des Projekts mit CVSS, betroffenen Spannen und Workaround: GHSA-2cvf-wqm6-wr9g, veröffentlicht 15.10.2026
• GitHub Advisory Database zum selben Fall: GHSA-2cvf-wqm6-wr9g
• CVE-Eintrag der CNA mit Vektor und CWE: cve.org, veröffentlicht 13.10.2026
• Revert des Run-Pfads: Commit 3721ff8, 28.09.2026
• Fix-Releases: v5.8.8 und v6.1.3, 29.09.2026
• Quelltext zur Annotation und zum Test: annotations.go in v5.8.7 und checkpoint_image_test.go

Distributoren und Kataloge

• Red Hat, CVE-Seite mit Bewertung und Produktständen: access.redhat.com, abgerufen 16.10.2026
• Debian, Security-Tracker: CVE-2026-94603
• Amazon Linux, CVSS 8.6: explore.alas.aws.amazon.com
• Fedora-Updates im Testing (Bot-Schutz, im Browser öffnen): bodhi.fedoraproject.org
• CISA, Katalog der ausgenutzten Schwachstellen, ohne Podman-Eintrag am 16.10.2026: cisa.gov

Community

• Hacker News, Suche nach Podman im Oktober 2026: keine Diskussion zu CVE-2026-94603