How severe is CVE-2026-94603?

CVE-2026-94603 has a CVSS score of 10/10, rated CRITICAL. Immediate patching is strongly recommended.

Which packages are affected by CVE-2026-94603?

CVE-2026-94603 affects the following packages: github.com/containers/podman (Go), go.podman.io/podman/v6 (Go). Ecosystems affected: Go.

How do I fix CVE-2026-94603?

Update github.com/containers/podman to 5.8.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-94603 is resolved across your whole dependency graph.

How do I detect CVE-2026-94603 in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/containers/podman, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2026-94603 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Is CVE-2026-94603 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-94603 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2026-94603?

CVE-2026-94603 has an EPSS (Exploit Prediction Scoring System) score of 0.9%, placing it in the 60th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2026-94603?

CVE-2026-94603 is classified as CWE-693 (CWE-693). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2026-94603 published, and has it been updated?

CVE-2026-94603 was published on October 13, 2026 and was last updated on October 23, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹

🐹 Go

Not in CISA KEV

CRITICAL severity

CVE-2026-94603 — podman

CRITICALFix: podman-container-tools/podman@2470629

CVE-2026-94603 is a critical-severity (CVSS 10) CWE-693 vulnerability in github.com/containers/podman. A fix is available for github.com/containers/podman — see the affected versions and patch details below.

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

Also known asGHSA-2cvf-wqm6-wr9gGO-2026-6770

Published

Oct 13, 2026

Updated

Oct 23, 2026

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗

0.9%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs60th percentile — riskier than 60% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-94603 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

2 pkgs affected

🐹github.com/containers/podman🐹go.podman.io/podman/v6

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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.

Credits

This vulnerability was discovered by ADA Logics Ltd using Anthropic's Claude models.

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/containers/podman`	≥ 4.4.0&&< 5.8.8	5.8.8`go get github.com/containers/podman@v5.8.8`
🐹Go	`go.podman.io/podman/v6`	≥ 6.0.0&&< 6.1.3	6.1.3`go get go.podman.io/podman/v6@v6.1.3`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/containers/podman, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/containers/podman to 5.8.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-94603 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

This vulnerability is rated as having an Important severity impact for Red Hat environments because running a malicious image can completely circumvent expected confinement boundaries and grant unexpected privileges to a container, compromising host integrity. Under default configurations, container execution relies…

Workaround published by Red Hat

Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.

Source: Red Hat security advisory for CVE-2026-94603 (CC BY 4.0)

Product	Fixed in	Advisory
Red Hat Enterprise Linux 10	`podman-7:5.8.2-10.el10_2`	RHSA-2026:88202
Red Hat Hardened Images	`podman-main-6.1.2-1.1.hum1`	RHSA-2026:74178
Red Hat Hardened Images	`podman-main-6.1.3-1.hum1`	RHSA-2026:74861
Red Hat Quay 3.12	`quay/quay-rhel8:1791314514`	RHSA-2026:79546

Frequently Asked Questions

### 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 d