CVE-2026-94603 is a Podman sandbox-boundary flaw involving specially annotated checkpoint images. In the affected path, podman run can treat an image as a checkpoint and ignore sandbox settings supplied by the operator, including restrictions intended to drop capabilities. [1]
This is not a generic “all containers are broken” advisory. The important question is whether a deployment can run checkpoint images through the affected Podman path, and whether its trust model assumes that command-line sandbox settings remain authoritative.
What does the Podman vulnerability change?
The image annotation io.podman.annotations.checkpoint.runtime.name can cause Podman to interpret an image as a checkpoint rather than an ordinary container image. Podman’s upstream release notes describe the security problem plainly: checkpoint execution could disable sandboxing, including sandboxing requested by the user. [2]
That creates a trust-boundary problem. An operator may believe that the invocation’s security options define the container’s confinement, while image-controlled checkpoint state can select a different execution model.
Why is --cap-drop=ALL not a complete answer here?
Dropping capabilities is useful only within the execution model that applies the setting. CVE-2026-94603 matters because the checkpoint path could cause user-supplied sandbox restrictions to be ignored, so a restrictive-looking invocation is not proof that the resulting process received the intended confinement. [1]
The practical lesson is narrower than “never trust container flags”: do not treat an image’s successful launch, a familiar command line, or a CVSS score as proof that the runtime used the expected security boundary. The image format and the runtime’s interpretation of its metadata matter too.
Are rootless Podman containers affected?
The NVD record says rootless containers are not affected because checkpoint and restore are unavailable in rootless mode. That is a scope statement about this checkpoint path, not a claim that rootless operation eliminates every Podman or container risk. [1]
Rootful deployments, or deployments where checkpoint restoration is available, deserve the closest review. The exact boundary still depends on the installed Podman build and the distribution’s packaging and backport policy.
Which Podman versions contain the upstream fix?
Podman’s release notes identify v5.8.8 and v6.1.3 as fixed upstream release lines. The project also says it removed checkpoint-image support from podman run because the security models for ordinary images and checkpoints are difficult to combine safely. [2][3]
Those are upstream version references, not a substitute for a distribution advisory. A vendor may backport the fix without matching the upstream version string, or may package a different release line. Do not infer a host’s exposure from a raw version comparison alone.
What should a small-team operator decide?
Use these questions to frame the review without assuming facts that have not been verified:
- Does the workload use Podman, and is the deployment rootful or otherwise capable of checkpoint restore?
- Could images arrive from outside a tightly controlled provenance path?
- Does the environment rely on user-supplied capability, privilege, or namespace settings as a primary boundary?
- Which distribution advisory or package record establishes the fixed state for the installed package?
- Is the deployment using a feature path that the upstream release notes say was removed or changed?
This brief intentionally does not provide update commands, package-inspection commands, or configuration changes. Those are operational instructions whose correctness depends on the distribution, release, access path, recovery plan, and evidence captured on the target host.
What this advisory does not prove
CVE-2026-94603 does not prove that every Podman container is exploitable, that every image is malicious, or that rootless containers share the same checkpoint exposure. Red Hat describes the issue as potentially affecting host integrity when a malicious image is run in affected environments, while the NVD and Podman sources define the feature and version boundaries. [1][2][4]
For adjacent container decisions, see Docker and Podman published-port exposure and Docker rootless versus rootful operation. Those pages address different boundaries; neither should be treated as a substitute for the Podman advisory’s checkpoint scope.
Sources
- NVD: CVE-2026-94603 — affected ranges and rootless scope.
- Podman v6.1.3 release notes — upstream fix description and checkpoint-image change.
- Podman v5.8.8 release notes — fixed release line.
- Red Hat: CVE-2026-94603 — Red Hat scope and impact description.