Like a TSA-approved lock that opens every suitcase in the airport when someone attaches the right luggage tag
CVE-2026-94603 is a sandbox bypass in Podman, the container runtime that ships as the default engine on Red Hat Enterprise Linux and holds roughly 23% enterprise container runtime market share. Any OCI container image carrying the io.podman.annotations.checkpoint.runtime.name annotation — a single metadata field — causes podman run to silently enter its CRIU checkpoint-restore code path. In that path, the container's security posture (seccomp profile, Linux capabilities, no_new_privs, AppArmor/SELinux labels) is populated from the checkpoint data embedded in the image rather than from the user's --security-opt, --cap-drop, or pod security policies. An attacker who crafts an image with this annotation can run processes as root with full capabilities and no seccomp enforcement, regardless of what the operator requested. Affected versions span Podman v4.x through < 5.8.8 and v6.x through < 6.1.3. The fix in both branches is drastic: checkpoint image support in podman run has been completely removed. The associated advisory is GHSA-2cvf-wqm6-wr9g.
No vendor or NVD CVSS score has been published for this CVE. The closely related containerd advisory (CVE-2026-95837 / GHSA-p7v4-vr35-mj6f) for the same vulnerability class was rated Critical by its maintainers with CWE-269, and CRI-O's equivalent (CVE-2026-92574) received similar urgency. However, Podman's standalone usage model — where a human or script explicitly invokes podman run — adds meaningful friction compared to containerd's Kubernetes-driven pod lifecycle, where images are pulled and launched automatically. The Podman team's decision to completely delete the feature rather than harden it confirms the design was fundamentally unsound, but the narrow trigger (a specific annotation on an image the victim must actively run) keeps the real-world risk below the containerd benchmark. noisgate assesses this at HIGH (8.2) — the sandbox bypass is total, but exploiting it requires supply-chain compromise or social engineering to get the annotated image into the victim's workflow.
5 steps from start to impact.
Craft malicious checkpoint image
io.podman.annotations.checkpoint.runtime.name annotation to its manifest. They embed checkpoint data that specifies full Linux capabilities (CAP_SYS_ADMIN, CAP_NET_ADMIN, etc.), disables seccomp filtering, and sets no_new_privs to false. This requires only podman build or skopeo copy --override-annotation — no special tooling or exploit development.- Knowledge of Podman checkpoint annotation format
- Ability to build and push OCI images
- The annotation name
io.podman.annotations.checkpoint.runtime.nameis specific and machine-detectable by registry admission policies
Distribute image to victim's registry or host
- Write access to a registry or build pipeline the victim consumes
- Or social engineering the victim into pulling a specific image
- Registry write access is gated by authentication and RBAC
- Image signing (cosign, Notary) flags tampered images when enforced
- Content trust policies prevent unsigned images from being pulled
Victim runs the image with podman run
podman run on the malicious image. Podman inspects the image manifest, detects the io.podman.annotations.checkpoint.runtime.name annotation, and silently switches from the normal container creation path to the checkpoint-restore path. The user receives no warning that sandbox settings are about to be overridden.- Podman < 5.8.8 (v5) or < 6.1.3 (v6) installed on the target
- CRIU installed on the target host
- User or automation executes
podman runon the attacker's image
- CRIU is not installed by default on RHEL, Fedora, Ubuntu, or Debian
- Victim must explicitly run the image — not remotely exploitable
- In rootless Podman the blast radius is limited to the user namespace
Sandbox controls silently bypassed
--cap-drop, --security-opt, or --read-only flags are silently ignored. The container now runs with full root capabilities and zero syscall filtering.- Steps 1-3 completed successfully
- SELinux in enforcing mode with container-selinux policies provides a secondary containment layer that still applies at the kernel level
Host compromise or supply-chain pivot
/proc/1/root, access the container runtime socket, or exploit local privilege escalation paths to escape the container. On CI/CD hosts this enables tampering with build artifacts and injecting backdoors into software supply chains. On production hosts this enables data exfiltration and lateral movement across the network.- Container running unsandboxed (step 4)
- Host has exploitable surfaces: mounted host paths, runtime socket, or kernel vulnerabilities
- Hosts with minimal surface area (no host mounts, no runtime socket exposed) limit post-exploitation even without sandbox
- Network segmentation contains lateral movement from a compromised container host
/proc/1/root access, and cgroup escape patterns.podman run, eliminating the vulnerable code path entirely. This is the definitive fix. Deploy within 30 days per noisgate mitigation SLA for HIGH, with full rollout completing within the 180-day noisgate remediation SLA.io.podman.annotations.checkpoint.runtime.name annotation. This catches the attack at image pull time before it reaches podman run. Deploy within 30 days per noisgate mitigation SLA for HIGH. A sample Kyverno ClusterPolicy matching on io.podman.annotations.checkpoint.* annotations covers this.rpm -q criu or dpkg -l criu. Deploy within 30 days.podman run. A tampered image with an injected checkpoint annotation would fail signature verification, blocking the primary supply-chain delivery vector. Deploy within 30 days.--security-opt/--cap-dropflags onpodman run— These are exactly what the vulnerability bypasses. Specifying restrictive security options has no effect when the checkpoint-restore code path overrides them with the attacker's embedded configuration.- Rootless Podman alone — While rootless mode limits the initial user namespace, the sandbox bypass still grants the container all capabilities within that user namespace. Combined with user-namespace escape techniques or kernel vulnerabilities, rootless mode is not a reliable standalone mitigation.
- Standard vulnerability scanners (Trivy, Grype, Snyk Container) — These tools inspect image layers for known CVEs in installed packages. They do not inspect OCI manifest annotations for checkpoint metadata. A malicious checkpoint image passes all standard container vulnerability scans clean.
- Network firewalling / WAF — The vulnerability is triggered locally by
podman run, not by inbound network traffic. No network-layer control addresses this attack vector.
The supporting signals.
| In-the-Wild Exploitation | No evidence. Not listed in CISA KEV. No GreyNoise or Shodan observations. No public reports of exploitation campaigns. The vulnerability class (checkpoint restore sandbox bypass) has not been observed in active exploitation across Podman, containerd, or CRI-O. |
|---|---|
| Proof of Concept | No public PoC indexed. pocindex.io shows no results for CVE-2026-94603. No GitHub repositories named after this CVE. However, weaponization is trivial — adding a single OCI annotation to any image triggers the vulnerable code path. No memory corruption or exploit development required. |
| EPSS Score | Not yet scored. FIRST EPSS has not published a probability for this CVE, likely because NVD has no enriched record. |
| CISA KEV Status | Not listed as of 2026-09-30. |
| CVSS Vector (noisgate-estimated) | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H → 8.6 (HIGH). Local attack vector (victim runs the image), no privileges needed to craft it, user interaction required, scope changed (sandbox boundary crossed), full CIA impact. |
| Affected Versions | Podman v4.x – v5.8.7 (v5 branch) and v6.0.0 – v6.1.2 (v6 branch). Checkpoint image support in podman run was introduced alongside CRIU integration in Podman 4.x. Podman 3.x and earlier are not affected. |
| Fixed Versions | Podman 5.8.8 (v5 branch) and Podman 6.1.3 (v6 branch). Fix removes checkpoint image support from podman run entirely (breaking change). Distro backport: Alpine 3.20 community/podman upgraded to 6.1.3. |
| Related Advisories | Same vulnerability class across all major container runtimes: CVE-2026-95837 (containerd, GHSA-p7v4-vr35-mj6f, rated Critical, CWE-269, fixed in 2.2.7/2.3.4), CVE-2026-92574 (CRI-O, affects 1.34+). All share the same root cause: CRIU restores process credentials from checkpoint data without enforcing destination security context. |
| Disclosure Date | Approximately 2026-09-15, based on Podman v5.8.8 and v6.1.3 release timelines. GHSA-2cvf-wqm6-wr9g is the associated GitHub Security Advisory. |
| Reporting Researcher | Not publicly credited in Podman release notes. The related containerd advisory credits @l2yyd5 and @berkpolatCE — likely the same researchers who identified the vulnerability class across runtimes. |
Sources.
- Podman v5.8.8 Release Notes (CVE-2026-94603 fix)
- Podman v6.1.3 Release Notes (CVE-2026-94603 fix)
- Containerd GHSA-p7v4-vr35-mj6f (related checkpoint sandbox bypass, CVE-2026-95837)
- CRI-O CVE-2026-92574 checkpoint restore privilege bypass
- Podman checkpoint/restore documentation
- CRIU Podman integration reference
- Podman security advisories (GHSA-2cvf-wqm6-wr9g)
- Podman vs Docker enterprise market share 2026
Why this verdict
- Complete sandbox nullification: The vulnerability strips away ALL user-specified container security controls — seccomp, capabilities, no_new_privs, AppArmor/SELinux OCI labels — silently and without warning. When it fires, the container runs with full root capabilities, making host compromise straightforward from within.
- Trivial weaponization, zero exploit development: Crafting a malicious image requires adding a single OCI annotation. No memory corruption, no shellcode, no binary exploit.
skopeo copy --override-annotationis the entire weaponization chain. The PoC writes itself. - Supply-chain blast radius in CI/CD: In CI/CD pipelines where Podman builds and runs images from registries, a compromised upstream image with the checkpoint annotation would silently disable all sandbox protections on the build host, enabling supply-chain pivot to downstream consumers.
- Role multiplier: Podman is canonically a container runtime (orchestration category in the high-value role catalog). In CI/CD roles (~15-25% of enterprise Podman deployments), the chain succeeds: malicious image enters pipeline → runs unsandboxed → attacker compromises build host → supply-chain pivot (fleet-scale blast radius). In production container host roles (~15-20%), sandbox bypass → host compromise → data exfiltration or lateral movement (host-to-tenant blast radius). In developer workstation roles (~50-60%), blast radius is limited to the user's local account (host-level, non-fleet). The high-value role floor pushes toward CRITICAL, but the specific attack vector (checkpoint annotation — an artifact of CRIU integration used by <1% of Podman users, as CRIU is not installed by default on any major distro and the Podman team removed the feature without a deprecation period, confirming minimal production adoption) narrows realistic exposure below the CRITICAL threshold.
- User interaction required (UI:R): The victim must explicitly
podman runthe malicious image. Unlike containerd in Kubernetes (where pod creation is automated by the kubelet), Podman's standalone model requires a human or script to pull and run the specific image. This is a meaningful friction point the containerd variant does not have. - CRIU dependency limits exploitability: Checkpoint-restore requires CRIU on the host. CRIU is not installed by default on RHEL, Fedora, Ubuntu, or Debian. Hosts without CRIU cannot complete the checkpoint restore flow, limiting the vulnerable population to the subset that has actively installed this optional package.
Why not higher?
The high-value role floor for canonical container runtimes points toward CRITICAL, and the containerd equivalent was rated Critical by its maintainers. However, breaking the CRITICAL floor is justified by specific installed-base evidence: (1) the checkpoint-restore code path requires CRIU, which is not installed by default on any major Linux distribution — Red Hat's own documentation treats it as an advanced/experimental feature, (2) the Podman team removed checkpoint image support from podman run without any deprecation period, confirming the feature had minimal production adoption (<1% of installed base), and (3) Podman's standalone usage model requires explicit user interaction to trigger the vulnerability, unlike containerd's automated Kubernetes pod lifecycle where images are consumed programmatically.
Why not lower?
The sandbox bypass is total — when triggered, it completely nullifies every container security control the operator configured. The trigger is trivially weaponizable (one annotation, no exploit development), and in CI/CD environments where Podman runs images from registries, the supply-chain blast radius is real and fleet-scale. The containerd and CRI-O equivalents were treated as Critical/High across the industry, establishing this vulnerability class as serious. Dropping below HIGH would understate the impact for the ~30-40% of enterprise Podman deployments sitting in CI/CD and production container host roles where the blast radius extends beyond a single workstation.
Crowdsourced verification payload.
Run this script on each target host where Podman is installed. Execute as any user with access to the podman binary. Usage: bash check_cve_2026_94603.sh. No root privileges required — the script checks the installed Podman version and CRIU availability without modifying the system.
#!/usr/bin/env bash
# check_cve_2026_94603.sh
# Verify whether host is vulnerable to CVE-2026-94603
# Podman checkpoint image annotation sandbox bypass
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -uo pipefail
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[0;33m'
NC='\033[0m'
# Check if podman is installed
if ! command -v podman &>/dev/null; then
echo -e "${GREEN}PATCHED${NC} — Podman is not installed on this host."
exit 0
fi
PODMAN_VERSION=$(podman --version 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+')
if [[ -z "${PODMAN_VERSION:-}" ]]; then
echo -e "${YELLOW}UNKNOWN${NC} — Could not determine Podman version."
exit 2
fi
echo "Detected Podman version: $PODMAN_VERSION"
# Parse major.minor.patch
IFS='.' read -r MAJOR MINOR PATCH <<< "$PODMAN_VERSION"
VULNERABLE=false
if [[ "$MAJOR" -lt 4 ]]; then
# v3.x and below: checkpoint image support not present
echo -e "${GREEN}PATCHED${NC} — Podman $PODMAN_VERSION predates checkpoint image support in podman run."
exit 0
elif [[ "$MAJOR" -eq 4 ]]; then
# v4.x: checkpoint images supported, no backport fix available
VULNERABLE=true
elif [[ "$MAJOR" -eq 5 ]]; then
# v5.x branch: vulnerable if < 5.8.8
if [[ "$MINOR" -lt 8 ]]; then
VULNERABLE=true
elif [[ "$MINOR" -eq 8 && "$PATCH" -lt 8 ]]; then
VULNERABLE=true
fi
elif [[ "$MAJOR" -eq 6 ]]; then
# v6.x branch: vulnerable if < 6.1.3
if [[ "$MINOR" -lt 1 ]]; then
VULNERABLE=true
elif [[ "$MINOR" -eq 1 && "$PATCH" -lt 3 ]]; then
VULNERABLE=true
fi
else
# v7.x+: presumably patched
echo -e "${GREEN}PATCHED${NC} — Podman $PODMAN_VERSION is newer than affected versions."
exit 0
fi
# Check CRIU availability (exploit requires CRIU for restore)
CRIU_INSTALLED=false
if command -v criu &>/dev/null; then
CRIU_INSTALLED=true
elif rpm -q criu &>/dev/null 2>&1; then
CRIU_INSTALLED=true
elif dpkg -l criu 2>/dev/null | grep -q '^ii'; then
CRIU_INSTALLED=true
fi
if $VULNERABLE; then
echo -e "${RED}VULNERABLE${NC} — Podman $PODMAN_VERSION is affected by CVE-2026-94603."
if $CRIU_INSTALLED; then
echo " [!] CRIU is installed — checkpoint restore is fully functional. Exploit is viable."
else
echo " [i] CRIU is NOT installed — exploit requires CRIU for checkpoint restore."
echo " Risk is reduced but the vulnerable code path exists. Upgrade recommended."
fi
echo ""
if [[ "$MAJOR" -eq 4 ]]; then
echo " Fix: No backport available for v4.x. Upgrade to Podman >= 5.8.8 or >= 6.1.3."
elif [[ "$MAJOR" -eq 5 ]]; then
echo " Fix: Upgrade to Podman >= 5.8.8."
elif [[ "$MAJOR" -eq 6 ]]; then
echo " Fix: Upgrade to Podman >= 6.1.3."
fi
exit 1
else
echo -e "${GREEN}PATCHED${NC} — Podman $PODMAN_VERSION is not affected by CVE-2026-94603."
exit 0
fi