CVE-2026-94603: 
Podman vulnerability analysis and mitigation

CVE-2026-94603 is a container sandbox bypass vulnerability in Podman, where the podman run command can be manipulated by checkpoint annotations embedded in a container image to silently ignore user-specified sandboxing options — including dropped privileges and capability restrictions. Introduced alongside the checkpoint distribution feature added in Podman v4.4.0, the flaw allows a specially crafted image to override security settings such as --cap-drop=ALL by setting the io.podman.annotations.checkpoint.runtime.name annotation. The CVE was reported on September 28, 2026, and published on September 29, 2026, with a patch confirmed available. It carries a CVSS v3.1 base score of 8.6 (High) (Red Hat Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-15 (External Control of System or Configuration Setting). Podman v4.4.0 introduced the ability to distribute container checkpoints via OCI registries and restore them using podman run. Podman identifies checkpoint images by checking for the annotation io.podman.annotations.checkpoint.runtime.name; if present, it treats the image as a restored checkpoint and silently discards all user-supplied sandboxing arguments (e.g., --cap-drop, --security-opt), instead using the capabilities and configuration embedded in the checkpoint image — which may include full Linux capabilities. An attacker can craft a malicious OCI image with this annotation set to arbitrary values, causing Podman to execute it with elevated privileges regardless of the operator's intent. The Podman maintainers determined the safest remediation was to remove the conflated checkpoint-from-registry functionality entirely (Red Hat Bugzilla, Red Hat Advisory).

Successful exploitation allows an unauthenticated local attacker — who can convince a user to run a malicious container image — to bypass container sandbox restrictions and execute code with elevated system privileges on the host. The changed scope (S:C) in the CVSS vector reflects that the impact extends beyond the container boundary to the underlying host system, with high confidentiality, integrity, and availability impact. This could enable full host compromise, lateral movement within a containerized environment, and access to sensitive data on the host (Red Hat Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of reporting. Exploitation requires user interaction — specifically, a user must be convinced to execute a specially crafted container image using podman run. The attack vector is local (AV:L), and no privileges are required from the attacker. The CVE status remains "Reserved" and no EPSS score or CISA KEV catalog entry has been reported (Red Hat Advisory, Feedly).

1. Craft a malicious OCI image: Create a container image and embed the annotation io.podman.annotations.checkpoint.runtime.name with any value (e.g., runc) in the image manifest. Configure the checkpoint metadata within the image to specify a permissive capability set, such as all Linux capabilities (CAP_SYS_ADMIN, CAP_NET_ADMIN, etc.).
2. Distribute the image: Push the crafted image to a public or accessible OCI registry (e.g., Docker Hub, Quay.io) or distribute it via other means (e.g., a tarball).
3. Social engineering: Convince a target user to pull and run the malicious image using podman run, potentially disguising it as a legitimate application or checkpoint.
4. Trigger sandbox bypass: When the user executes podman run [options] malicious-image, Podman detects the checkpoint annotation and silently ignores all user-supplied sandboxing flags (e.g., --cap-drop=ALL, --security-opt=no-new-privileges), substituting the attacker-controlled capability set from the image.
5. Achieve elevated execution: The container starts with the attacker-specified capabilities and configuration, potentially including full Linux capabilities, enabling container escape or privileged operations on the host (Red Hat Bugzilla, Red Hat Advisory).

• Container Image Metadata: Container images with the annotation io.podman.annotations.checkpoint.runtime.name set, especially from untrusted or unexpected sources; inspect with podman inspect <image> or skopeo inspect.
• Logs: Podman logs showing podman run invocations where user-supplied --cap-drop or --security-opt flags were silently overridden; audit logs showing containers launched with unexpected capability sets.
• Process: Container processes running with elevated Linux capabilities (e.g., CAP_SYS_ADMIN) despite operator intent to restrict them; use podman inspect <container> to review CapAdd/CapDrop fields post-launch.
• Network: Unexpected outbound connections from container processes to external hosts, potentially indicating post-exploitation activity such as reverse shells or data exfiltration.

The Podman maintainers have determined that the safest remediation is to remove the checkpoint-from-registry functionality that conflates container images and checkpoints in podman run. Users should update Podman to the patched version that enforces sandboxing options regardless of checkpoint annotations (check the fixed version field in the Red Hat Bugzilla tracker for the specific release). As an interim measure, avoid running container images from untrusted sources, and implement image scanning and validation policies to detect suspicious checkpoint annotations (e.g., io.podman.annotations.checkpoint.runtime.name) before execution (Red Hat Bugzilla, Red Hat Advisory).

The Podman project acknowledged the vulnerability via their Mastodon account shortly after disclosure (Podman Mastodon). Community discussion appeared on Reddit's r/podman, where users discussed the CVE alongside a related tool called egresslock (Reddit). The vulnerability was also covered in security news outlets and package management newsletters, reflecting moderate community interest given its local attack vector and user-interaction requirement (Security Online).