Podman Checkpoint-Image Confusion Let Container Images Silently Disable Sandboxing (CVE-2026-94603)

What happened

The Podman Maintainers published a critical security advisory (GHSA-2cvf-wqm6-wr9g, CVE-2026-94603, CVSS 10.0) disclosing that podman run can be made to ignore nearly all caller-specified sandboxing options. Since Podman v4.4.0, container checkpoints created via podman container checkpoint could be distributed through an OCI registry and launched with podman run. Podman identifies a checkpoint by looking for the io.podman.annotations.checkpoint.runtime.name image annotation — but any image can set that annotation. When present, Podman silently discards the user's runtime flags (e.g. --cap-drop=ALL) and instead applies whatever sandbox configuration — including capabilities — is embedded in the checkpoint itself. The vendor's fix is a straight revert of the feature across main, v6.1, and v5.8. According to the advisory, rootless containers are not affected, since they do not support checkpoint/restore. A public PoC reportedly exists per the advisory's exploit status.

Why it matters for defenders

This is a container-escape-adjacent trust-boundary failure: an attacker who can get a crafted image pulled and run rootful via podman run — through a compromised registry, a poisoned base image, or a supply-chain substitution — can override hardening flags your deployment pipeline relies on, potentially granting the container full capabilities regardless of what operators intended. Anyone running rootful Podman and pulling third-party or externally-sourced images is affected; this is squarely a problem for CI runners, build hosts, and any environment that still runs containers as root.

What defenders should watch for or do now

• Patch Podman to a build that includes the revert (main, v6.1, and v5.8 branches per the advisory commit list) as soon as it's available in your distro/package channel.
• Until patched, scan pulled images for the io.podman.annotations.checkpoint.runtime.name annotation and reject any that carry it — Podman itself does not do this automatically yet.
• Where feasible, prefer rootless Podman, which the advisory states is not affected by this checkpoint/restore path.
• Audit image-pull and registry-mirror policies for rootful hosts; treat any unexpected checkpoint-style image metadata as a signal worth alerting on in your image-scanning or admission-control tooling.
• Review CI/build infrastructure that runs podman run as root against externally supplied images — this is the highest-risk exposure path.

Developing intel

This is a same-day disclosure and detail is still limited to the GHSA advisory itself; there is no confirmed in-the-wild exploitation or ransomware linkage reported at this time. Treat this writeup as preliminary and consult the original advisory for authoritative patch commits and updates: GHSA-2cvf-wqm6-wr9g.