containers

Podman v6.1.3 removed a feature that let a container image override your sandbox settings

CVE-2026-94603 (CVSS 10.0) let any image bearing a checkpoint annotation instruct `podman run` to disable almost all sandboxing, including the flags you explicitly set. The fix in v6.1.3 is a breaking change, not a quiet patch.

Glenn Fryklund

Glenn Fryklund

— 3 min read
Share
Podman v6.1.3 removed a feature that let a container image override your sandbox settings
Rendered with AI. A metal container door with a padlock and a small orange barcode tag clipped to the lock, standing in for a checkpoint image whose single annotation overrides the operator's sandbox flags.

When you type podman run --cap-drop=ALL, you are telling the runtime to strip every capability from the container. On Podman v4.4.0 through v5.8.7, that instruction could be ignored. If the image you were running carried a single annotation, the runtime would quietly drop your request and use the capability set baked into the image instead.

The vulnerability is CVE-2026-94603, rated CVSS 10.0 by NIST. The mechanism is a trust boundary most operators never think about: image annotations.

Podman v4.4.0 added the ability to distribute container checkpoints through an OCI registry. A checkpoint is a snapshot of a running container, and when you pull it and run it with podman run, it carries complete control of how the container is created, including full control of the sandbox. The trigger is a single annotation, io.podman.annotations.checkpoint.runtime.name. Any image bearing that annotation is treated as a checkpoint, and podman run silently ignores all user input about container creation. Your --cap-drop=ALL is dropped in favor of the checkpoint's capability set.

So an attacker who can supply an image, or an image bearing that one annotation, can instruct podman run to disable almost all sandboxing, including the sandboxing you explicitly requested. For a self-hosted or homelab deployment that pulls and runs images from a registry, that is a direct path from a malicious image to a container running with capabilities it was never supposed to have.

The fix is where this story gets interesting. It is not a quiet patch. Podman v5.8.8 and v6.1.3 both address the CVE, but the v6.1.3 fix is a breaking change: it removed checkpoint-image support from podman run entirely. The release notes say checkpoints "ignore user-specified security configuration and are very difficult to run safely." The vendor's own conclusion is that the feature could not be made safe while it stayed, so they deleted it.

That is the point worth sitting with. The annotation-based checkpoint feature was a trust boundary that silently overrode explicit user security settings. The image, not the operator, got the final word on sandboxing. The same class of failure shows up in other container runtimes, where a metadata field on the image can steer how the runtime configures the container.

Two things to do if you run Podman. First, upgrade. The affected ranges are v4.4.0 to below v5.8.8 (fixed in 5.8.8) and v6.0.0 to below v6.1.3 (fixed in 6.1.3). If you are on the v6 line and rely on running checkpoint images through podman run, the v6.1.3 update will stop that working, so check what you are running before you bump. Second, treat any image you can run through podman run as untrusted input. An annotation on the image can override your sandbox flags, so do not assume the flags you type are the ones that take effect.

As of 2026-10-17 there is no CISA KEV listing and no confirmed in-the-wild exploitation. This is a defensive story: upgrade and audit checkpoint-image handling in self-hosted container deployments, not an active-exploitation story.

Sources

This article was drafted with AI/LLM assistance and reviewed by a human before publication. All factual claims were checked against the public sources cited above. The feature image was generated with AI. See How we use AI for the full workflow.

Topics:

Read more