CVE-2026-94603: Podman: The `podman run` command can be instructed to disable almost all sandboxing by image annotation

Should you act?

Critical and remotely reachable

No known exploitation yet, but it is network-reachable without credentials. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.

• No confirmed exploitation. It is not in CISA’s KEV catalog and CISA’s SSVC assessment records no known exploitation. That can change quickly after a public write-up; re-check if you are affected.
• EPSS 0.9%, percentile 60: FIRST’s model estimates a 0.9% chance of exploitation activity in the next 30 days, higher than 60% of all scored CVEs (moderate). EPSS is a probability, not a verdict.
• Remotely reachable with no login and no user interaction. If the vulnerable service is exposed to the internet, prioritize it.
• Only applies if your dependency tree includes github.com/containers/podman (Go) >= 4.4.0, < 5.8.8, fixed in 5.8.8; go.podman.io/podman/v6 (Go) >= 6.0.0, < 6.1.3, fixed in 6.1.3. Check your lockfile, including transitive dependencies.
• Editorial verdict: Check exposure. Podman CVE-2026-94603: Images Can Disable the Sandbox — If you run third-party images with rootful Podman, upgrade to 5.8.8 or 6.1.3 now, because an image can switch off the sandbox you asked for; rootless Podman and trusted-image-only hosts can patch on a normal cycle.

What it is

Podman is a tool for managing OCI containers and pods. From 4.4.0 until 5.8.8 and 6.1.3, podman run treats an image carrying the io.podman.annotations.checkpoint.runtime.name annotation as a checkpoint and silently ignores user-supplied container creation restrictions such as --cap-drop=ALL, allowing image-controlled checkpoint state to select weaker sandbox settings and capabilities. Rootless containers are not affected because checkpoint and restore are unavailable in that mode. This issue is fixed in versions 5.8.8 and 6.1.3.

From the GitHub advisory

Impact Podman v4.4.0 added a feature where container checkpoints (from the podman container checkpoint command) could be distributed via OCI registry, and pulled from that registry and run via the podman run command. This allowed easy transfer of checkpoints between systems. However, checkpoints allow complete control of how the container is created - including full control of the container sandbox. When podman run detects a checkpoint, it will silently ignore all user input regarding how the container should be created - for example, podman run --cap-drop=ALL on an image that is determined to be a checkpoint will ignore --cap-drop=all and use the set of capabilities specified by the checkpoint image instead, which could include all capabilities. Podman identifies checkpoint images by looking for an annotation, io.podman.annotations.checkpoint.runtime.name. If this annotation is set, the image is treated as a checkpoint. Conflating container images and checkpoints in podman run allows inherently insecure behavior as the image can now control how it is executed. The Podman Maintainers have determined that the safest course of action is to remove this functionality.

Patch The commit introducing this functionality was reverted.

3721ff82ffb44a4ceeaecc5abd3808e924a6b669 c74b1d37b3fb834b0de43e176565d9d8c254b627 fa6cef22c2baf3987b581c673bb416ef0585daf7 (main) ea9243e04d1db3886dc3a51ee3300ffb547cfc02 450c64426dbcff1097d3c7911d791101e3d16f4c 2d05a7c61f022d4f24980ea6d307fa53da2b8692 (v6.1) 7728ba0a90094408ad9078e36c3622a651d49616 24706290d5c974f078d8ca284026802515f28e92 29c8c6e50607df7a7d735ace09ff0ea099c0b3e0 (v5.8)

Workarounds Images being pulled should be scanned for the io.podman.annotations.checkpoint.runtime.name annotation, and rejected if it is present. Podman does not presently have the ability to perform this scanning and rejection automatically.

Also not that rootless containers are not affected as they do not support checkpoint/restore at all currently.

Weakness type: CWE-693.

Product: github.com/containers/podman (Go) · Assigned by: GitHub_M · Published: 2026-10-13

Affected and fixed versions

Severity scores

• Attack vector: network (remotely reachable)
• Attack complexity: low
• Privileges required: none (no login)
• User interaction: none
• Scope: changed (can affect other components)

CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.

Exploitation and urgency

• CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
• CISA SSVC assessment: exploitation none, automatable yes, technical impact total.
• FIRST EPSS (model of 2026-10-21): 0.92% probability of exploitation activity in the next 30 days; percentile 60.

Timeline

• 2026-10-13 — CVE record last updated
• 2026-10-13 — CVE record published by GitHub_M
• 2026-10-13 — erroneo.us brief: Podman CVE-2026-94603: Images Can Disable the Sandbox
• 2026-10-15 — GitHub-reviewed advisory GHSA-2cvf-wqm6-wr9g published (critical)

Sources and references

Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.

Vulnerability records

1. GitHub Advisory GHSA-2cvf-wqm6-wr9g github.com
2. CVE.org record CVE-2026-94603 cve.org
3. NVD entry CVE-2026-94603 nvd.nist.gov

Other references from the CVE record and advisory

1. github.com github.com
2. github.com github.com
3. github.com github.com
4. github.com github.com
5. github.com github.com
6. github.com github.com
7. github.com github.com
8. github.com github.com
9. github.com github.com

Critical Go advisories · Today’s Security Digest