Podman CVE-2026-94603: Images Can Disable the Sandbox

What to do

1. Check versions on every host and runner: podman --version and sudo podman --version.
2. Upgrade to Podman 5.8.8 or 6.1.3, or your distribution's patched package (dnf update podman / apt-get install --only-upgrade podman), once available.
3. Until patched, do not run untrusted images with rootful Podman; use rootless Podman for third-party images.
4. Reject images that carry the io.podman.annotations.checkpoint.runtime.name annotation in admission scripts or CI before running them.
5. Review CI pipelines that run sudo podman run against images from pull requests or public registries.

How to check if you are affected or compromised

• List annotations on local images: sudo podman image inspect --format '{{json .Annotations}}' IMAGE and look for io.podman.annotations.checkpoint.runtime.name.
• For running rootful containers, compare sudo podman inspect --format '{{.EffectiveCaps}}' CONTAINER with the flags you passed; unexpected full capability sets are a red flag.
• Search shell history, CI logs and Quadlet units for rootful podman run of images from untrusted sources since Podman 4.4.0 was installed.

What happened#

Since version 4.4.0, Podman has been able to pull container checkpoints from an OCI registry and start them with podman run. A checkpoint carries a complete description of how its container is created, including the sandbox. According to the Podman advisory, when podman run sees an image with the annotation io.podman.annotations.checkpoint.runtime.name, it treats the image as a checkpoint. It then "silently ignore[s] all user input regarding how the container should be created." In the advisory's example, podman run --cap-drop=ALL on such an image ignores the flag and applies whatever capabilities the image specifies, which could be all of them.

Any image author can set that annotation. A malicious image can therefore switch off the isolation the operator asked for. The maintainers concluded that images and checkpoints cannot safely share podman run, and they removed the feature by reverting the commit that added it. Fixed releases 5.8.8 and 6.1.3 shipped on September 29, 2026. CVE-2026-94603 was published on October 13. The advisory credits ADA Logics, which found the bug using Anthropic's Claude models.

Who is affected#

Podman 4.4.0 through 5.8.7 and 6.0.0 through 6.1.2 are affected when run as root. The advisory states that rootless containers are not affected, because rootless Podman does not support checkpoint/restore. That narrows real exposure to rootful use: sudo podman run, root systemd and Quadlet units, and CI runners that use rootful Podman for speed or device access.

Distribution packaging lags upstream. Red Hat rates the issue Important. Its security data lists Podman in RHEL 8, 9 and 10, OpenShift and Podman Desktop as affected with no fix yet as of October 21, 2026. Fixes have shipped for Red Hat Hardened Images (podman 6.1.3, RHSA-2026:74861) and Quay 3.12 (RHSA-2026:79546). The Amazon Linux security center lists Amazon Linux 2023 buildah as not affected. Check your distribution's package changelog for the revert, not just the upstream version number.

Do you really need to act?#

The score depends on who you ask. The CVE record from GitHub's CNA scores it CVSS 3.1 10.0. Red Hat and Amazon score it 8.6, with a local attack vector and user interaction required. The lower score fits reality better: nothing happens until someone runs the attacker's image. NVD had not analyzed it as of October 21, 2026. CISA's ADP enrichment records exploitation as "none", and the CVE is not in KEV.

Running other people's images is routine, though: base images, tools from public registries, images built from pull requests. If any of that happens under rootful Podman, the sandbox flags in your scripts are not guaranteed to apply, and the image can ask for every capability. Red Hat notes that "Exploitation requires an operator or automated workflow to launch an untrusted image," so hosts that run only vetted images from your own registry are at lower risk.

What to do now#

1. Inventory versions with podman --version and sudo podman --version on developer machines, servers and CI runners.
2. Upgrade to 5.8.8 or 6.1.3, or your distribution's patched build (dnf update podman, apt-get install --only-upgrade podman) once it is published.
3. Until then, run third-party images rootless. If root is unavoidable, check the image annotation before running it.
4. Add a pre-run check to CI or deployment scripts that rejects any image whose annotations include io.podman.annotations.checkpoint.runtime.name. Podman cannot do this automatically, according to the advisory.

How to tell if you were hit#

Check images already pulled into root storage with sudo podman image inspect --format '{{json .Annotations}}' IMAGE and look for the checkpoint annotation. For running rootful containers, compare sudo podman inspect --format '{{.EffectiveCaps}}' CONTAINER with the capabilities you requested. A container that was asked to drop everything but holds a full capability set deserves investigation. Review CI logs and Quadlet units for rootful runs of external images, and treat any host that ran an annotated image as root as potentially compromised.

Timeline#

• Sep 29, 2026 — Podman 5.8.8 and 6.1.3 ship, removing checkpoint images from podman run.
• Oct 13, 2026 — CVE-2026-94603 is published with a CNA score of CVSS 3.1 10.0, and CISA's ADP records no known exploitation.
• Oct 15, 2026 — The advisory is added to the GitHub Advisory Database as GHSA-2cvf-wqm6-wr9g.

Vulnerability records

• CVE-2026-94603 · Podman is a tool for managing OCI containers and pods.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Podman — GHSA-2cvf-wqm6-wr9g: podman run can be instructed to disable almost all sandboxing by image annotation github.com
2. CVE record — CVE-2026-94603 cve.org
3. NVD — CVE-2026-94603 nvd.nist.gov
4. Podman — v5.8.8 release notes github.com
5. Podman — v6.1.3 release notes github.com
6. Red Hat — CVE-2026-94603 access.redhat.com
7. Red Hat Security Data API — CVE-2026-94603 access.redhat.com
8. Amazon Linux Security Center — CVE-2026-94603 explore.alas.aws.amazon.com