Security

Security2026-10-16· By Franz Senn

Podman CVE-2026-94603: an image annotation switches the sandbox off

On 29 September 2026 the Podman maintainers removed a feature in versions 5.8.8 and 6.1.3 instead of patching it. Behind it sits CVE-2026-94603: podman run accepted any image carrying a particular annotation as a checkpoint and restored the container with the security settings stored in the image. The restrictions the operator had set on the command line then no longer applied. The project's public advisory followed on 15 October 2026, with CVSS 10.0.

Podman is packaged by RHEL, Fedora, Debian and Ubuntu. (Quelle: Wikimedia Commons, file Podman-logo-orig.png, licence Apache 2.0, Podman)

The bug is not new. The feature arrived with Podman 4.4.0, released on 1 February 2023. Every release from there up to 5.8.7 and up to 6.1.2 is affected, as the project's own advisory lists.

What happens on `podman run`

Since 4.4.0 a state created with podman container checkpoint can be pushed to a registry as an image and run on another machine. That is handy for moving workloads between systems, and it is exactly where the problem sits. Detection rests on a single image annotation, io.podman.annotations.checkpoint.runtime.name. If it is set, podman run treats the image as a checkpoint.

The revert commit of 28 September 2026 (author Matt Heon) shows the spot in the source. The run path checks whether the annotation is present in the image and, if so, calls ContainerRestore internally before any user options are processed. The commit message is plain: "This commit has been identified as a serious security issue." A --cap-drop=ALL on a checkpoint image is ignored, the capability set comes from the image. The advisory names weaker sandbox settings and capabilities of the image's choosing as the result.

According to the project, rootless containers are not affected, because checkpoint and restore are not supported in that mode. It is the one piece of good news here, and at least a structural one.

Five steps, no operator error: the switch is set inside the image. Source: advisory GHSA-2cvf-wqm6-wr9g and revert commit 3721ff8 of 28 Sep 2026. (Quelle: GitHub advisory GHSA-2cvf-wqm6-wr9g, Podman source v5.8.7)

Two scores, two vectors

The maintainer and Red Hat arrive at different numbers, and the gap is worth a look because it explains your own priority.

The CVE record from the CNA GitHub (published 13 October 2026, CWE-693 Protection Mechanism Failure) carries CVSS 3.1 with 10.0 and the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Red Hat scores the same flaw at 8.6 with CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, rated Important and filed as CWE-15, public date 29 September 2026. Ubuntu's CVE page lists the maintainer's 10.0 as cvss3 but sets its own priority to medium. On 16 October the NVD still had no record of its own for the CVE (request to the NVD interface: HTTP 404).

The dispute sits in two fields: AV:N against AV:L and UI:N against UI:R. The maintainer assumes an attacker who gets an image into a pipeline without being on the target system. Red Hat counts the person or automation job that starts the image as a required condition and writes it down: exploitation requires an operator or workflow to start an unvetted image, and environments that only run vetted images from trusted registries carry reduced risk. Asked whether a mitigation exists, Red Hat answers with a plain no: none that meets its criteria.

Both numbers are primary statements, neither is a measurement. Anyone deciding for a company can translate the gap directly. If CI runs or self-service environments exist where someone starts a foreign image, the impact is closer to the 10.0. If only your own build from your own registry runs, Red Hat's reading is the more realistic one.

Two recorded values, the NVD does not list the CVE yet (HTTP 404 on 16 Oct 2026). The 10.0 describes the impact on the least favourable path, the 8.6 the same impact with a start by an operator as a precondition. Ubuntu lists the CVE with its own priority, medium. (Quelle: CVE record (CNA GitHub), Red Hat Security Data, Ubuntu CVE page, retrieved 16 Oct 2026)

What the distributors have delivered

Upstream the matter has been closed since 29 September, the current branches are 5.8.9 and 6.1.4 (both 12 October 2026). In real deployments the state lags behind. We read the following table directly at the distributors on 16 October.

Branch	Measured state	Status
Debian 13 (trixie)	5.4.2+ds1-2	vulnerable, fix only in sid (5.8.6+ds1-3)
Debian forky	5.8.6+ds1-2	vulnerable
Ubuntu	CVE listed, cvss3 10.0, priority medium	per-release status not in the API we read
Fedora 43 and 44	podman-5.8.9-1 in testing since 14 Oct	no stable update yet
Fedora 45	podman-6.1.4-1 in testing since 13 Oct	no stable update yet
RHEL 8, 9, 10	podman marked Affected	no errata for the podman packages
Red Hat Hardened Images	podman-main-6.1.2-1.1.hum1	RHSA-2026:74178 (1 Oct), then 6.1.3-1.hum1 (RHSA-2026:74861, 2 Oct)
Red Hat Quay 3.12	quay/quay-rhel8:1791314514	RHSA-2026:79546 (8 Oct)
OpenShift 4	podman marked Affected	open

Debian lists trixie as vulnerable in its security tracker, and the fixed state exists only in sid. Anyone running Debian 13 on a server is tied to a branch that is not being patched. Red Hat lists podman on RHEL 8, 9 and 10 and on OpenShift 4 as Affected; the existing notices concern the Hardened Images and Quay. At Fedora the updates have been in testing since 13 and 14 October. SUSE was not reachable from this container (HTTP 000, even with a browser user agent), so we say nothing about it.

A look at our own fleet

Read on 16 Oct 2026 via ssh over hostname, podman --version and the package manager. 21 of 30 hosts queried were reachable; six Proxmox nodes and pbs1 did not answer on TCP 22. 20 of the 21 hosts run Docker with 133 running containers in total. Podman is installed on none of them. (Quelle: Our own measurement, 16 Oct 2026)

The package manager's candidate decides what an apt install podman or an update would actually deliver on one of our hosts. Ubuntu 24.04 would bring 4.9.3, Ubuntu 26.04 would bring 5.7.0, Debian 13 would bring 5.4.2. All three fall inside the affected range. On the Alpine 3.23 host we checked, the repo listing had no line for podman, and we did not look further.

We could not reproduce the bug. There is no Podman in our estate and no skopeo on the host we checked, so we would first have had to build a vulnerable environment. The mechanism in this whole article therefore comes from the source and the advisory, and our contribution is the operational reading. By the sources, Docker on our 20 hosts is not affected: the faulty switch sits in Podman's run path, and the fix is a revert in that branch.

Our source pool listed this CVE exactly once in the nightly run at 05:45, namely the GitHub advisory itself. Of 324 active sources 309 worked, and ten have been collecting errors for at least two weeks.

What other sources say

Amazon Linux lists the CVE with CVSS 8.6 in its database, so with Red Hat and not with the maintainer. Security portals such as securityonline and thehackerwire repeated the report, and their texts sometimes give other ranges or numbers than the advisory, so we did not use them as sources. We looked for forum discussion (Hacker News, as of 16 October 2026) and found none on this CVE. The only Podman item there that week was the launch of a deploy tool for Docker and Podman. Anyone who wants to discuss the case in practice will find it in the project's advisory.

What operators should check now

Start with podman --version. By the advisory, the affected ranges are 4.4.0 up to below 5.8.8 and 6.0.0 up to below 6.1.3. Running rootless is immune to exactly this path according to the project, because there is no checkpoint and no restore there. On servers whose distribution package is still stuck, that is the lever that works today, provided the application cooperates.

The second line is the question of who builds your images. An image from a registry is a program you start, and here it even brings the sandbox parameters with it. Anyone running CI jobs with images from pull requests should take this flaw as one more reason to handle foreign images in a separate, tightly confined stage. Our pattern for that is in Four files before installation.

The third line is the check itself. Podman does not inspect the annotation on its own, the advisory says so explicitly, so a scan before start is all that is left. The field is called Annotations and is part of the project's inspect output, confirmed by the source and the matching e2e test of version 5.8.7:

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

A hit means: reject the image. On the registry side, before the pull, the same scan has to run as a policy. No distributor does that for you.

That leaves the update. Upstream it has been out for two and a half weeks, while Debian stable and RHEL still do not ship it in the package. Anyone who cannot move to rootless there stays dependent on building from source. That is inconvenient, and it is what a CVSS 10.0 costs while the distributor has not delivered.

How we measured

On 16 October 2026 we queried 30 hosts over ssh and 21 answered. On each host we read hostname and podman --version, the package manager's candidate through apt-cache policy podman or the Alpine package search, and the running containers through docker ps. Podman was installed on none of the hosts reached, and 20 of the 21 ran Docker with 133 containers in total. The distributor table comes from their databases of the same day. Bodhi (Fedora) sits behind a bot wall and can only be opened in a browser. We did not replay the annotation check on a vulnerable system because we have none.