CVE-2026-94603: Podman Privilege Escalation Vulnerability

CVE-2026-94603 Overview

CVE-2026-94603 is a security bypass vulnerability in Podman, a widely used tool for managing Open Container Initiative (OCI) containers and pods. The flaw affects podman run when processing images that carry the io.podman.annotations.checkpoint.runtime.name annotation. Podman treats such images as checkpoint restores and silently ignores user-supplied container creation restrictions, including --cap-drop=ALL. This allows image-controlled checkpoint state to select weaker sandbox settings and capabilities than the operator requested. The vulnerability affects versions 4.4.0 through 5.8.7 and 6.0.0 through 6.1.2. Rootless containers are not affected because checkpoint and restore are unavailable in that mode.

Critical Impact
A malicious container image can override operator-supplied security restrictions and gain elevated Linux capabilities, breaking the container sandbox boundary on rootful Podman hosts.

Affected Products

Podman versions 4.4.0 through 5.8.7
Podman versions 6.0.0 through 6.1.2
Rootful Podman deployments on Linux hosts supporting checkpoint and restore (CRIU)

Discovery Timeline

2026-10-13 - CVE-2026-94603 published to the National Vulnerability Database (NVD)
2026-10-13 - Last updated in NVD database
2026-10-13 - Fixed versions 5.8.8 and 6.1.3 released by the Podman project

Technical Details for CVE-2026-94603

Vulnerability Analysis

Podman supports container checkpoint and restore via CRIU, with checkpoint state distributable as an OCI image. To identify these images, Podman inspects the io.podman.annotations.checkpoint.runtime.name annotation. When present, podman run routes the request through the restore code path rather than the normal container creation path. The restore path reconstructs the container from serialized state embedded in the image, including capability sets, seccomp profiles, and namespace configuration. Operator-supplied flags such as --cap-drop=ALL, --security-opt, and related sandbox controls are silently discarded. An attacker who can convince an operator to run a crafted image can therefore select the effective capability set and sandbox profile. The underlying weakness is categorized as [CWE-693: Protection Mechanism Failure].

Root Cause

The root cause is improper trust of image-controlled metadata during container startup. Checkpoint restore inherits state from the image rather than from command-line flags, but Podman never warned the operator or enforced that explicit restrictions take precedence. The upstream fix reverts the earlier change that enabled podman run on checkpoint images, closing the implicit restore path.

Attack Vector

An attacker publishes or substitutes an OCI image that carries the io.podman.annotations.checkpoint.runtime.name annotation and embeds a permissive checkpoint state (for example, retaining CAP_SYS_ADMIN). When an operator runs the image with hardening flags, Podman restores the container with the image's capability set instead. The resulting container has broader kernel access than intended, which can be used to escape the sandbox on rootful hosts.

// Security patch: pkg/domain/infra/abi/containers.go
// Reverts "Enable 'podman run' for checkpoint images"
 	"fmt"
 	"maps"
 	"os"
-	"reflect"
 	"strconv"
 	"sync"
 	"time"

// Source: https://github.com/podman-container-tools/podman/commit/3721ff82ffb44a4ceeaecc5abd3808e924a6b669

The patch removes the reflection-based handling that allowed podman run to dispatch into the checkpoint restore flow. A matching change in pkg/domain/infra/tunnel/containers.go applies the same revert to the remote client. See the Podman Security Advisory GHSA-2cvf-wqm6-wr9g for the full fix set.

Detection Methods for CVE-2026-94603

Indicators of Compromise

Container images containing the io.podman.annotations.checkpoint.runtime.name annotation from untrusted registries
Running containers on rootful Podman hosts whose effective capability set exceeds what the invoking command line requested
Unexpected CRIU restore activity (criu process invocations) correlated with podman run commands
Audit log entries showing containers started with capabilities such as CAP_SYS_ADMIN despite --cap-drop=ALL in the invoking command

Detection Strategies

Inspect images with podman inspect or skopeo inspect --raw and alert on the presence of the io.podman.annotations.checkpoint.runtime.name annotation
Compare the capability set reported by /proc/<pid>/status (CapEff) for container processes against the capabilities requested on the Podman command line
Query container runtime telemetry for podman run invocations where the restore code path was taken
Monitor OCI registries for images tagged or annotated as checkpoints originating outside approved build pipelines

Monitoring Recommendations

Centralize Podman and auditd logs and alert on CRIU process execution under the Podman service account
Baseline the capability profile of production containers and alert on deviations
Track Podman binary versions across the fleet and flag hosts running vulnerable 4.4.0–5.8.7 or 6.0.0–6.1.2 releases

How to Mitigate CVE-2026-94603

Immediate Actions Required

Upgrade Podman to version 5.8.8 or 6.1.3 on all rootful hosts
Audit pulled images and registries for any artifacts carrying the io.podman.annotations.checkpoint.runtime.name annotation
Restrict image pulls to vetted internal registries and enforce signature verification with podman image trust
Review recent podman run activity on rootful hosts for restore events that bypassed hardening flags

Patch Information

The Podman maintainers released fixes in Podman v5.8.8 and Podman v6.1.3. The primary fix reverts the change that enabled podman run to operate on checkpoint images. See the referenced commits 24706290, 3721ff82, 450c6442, 7728ba0a, c74b1d37, and ea9243e0.

Workarounds

Run containers in rootless mode where possible, as checkpoint and restore are unavailable and the issue does not apply
Block or remove images carrying the io.podman.annotations.checkpoint.runtime.name annotation from internal registries until hosts are patched
Use podman container restore explicitly from trusted artifacts and avoid podman run against checkpoint images
Enforce admission policies that reject unsigned or externally sourced OCI images on production hosts

bash

# Verify installed Podman version and reject vulnerable builds
podman --version

# Inspect an image for the checkpoint annotation before running
skopeo inspect --raw docker://registry.example.com/myimage:tag \
  | jq '.annotations."io.podman.annotations.checkpoint.runtime.name"'

# Enforce signature-based image trust (rootful host)
sudo podman image trust set -t signedBy \
  -f /etc/pki/containers/approved.pub \
  registry.example.com