Podman Checkpoint CVE: How a Sandbox Bypass Works

Q: Does CVE-2026-94603 affect rootless Podman?

No. Both Red Hat's advisory and the GitHub security advisory confirm rootless containers aren't affected, because checkpoint and restore requires CRIU privileges that rootless mode doesn't have.

Q: What's the real CVSS score for this podman checkpoint bug?

Sources disagree. NVD lists 10.0 (Critical) based on the GitHub advisory's network/no-interaction scoring. Red Hat lists 8.6 (Important), scoring the attack vector as local with required user interaction, which matches how the bug is actually triggered.

Q: What annotation triggers the bypass?

`io.podman.annotations.checkpoint.runtime.name`. Any image carrying it gets treated as a checkpoint restore by vulnerable versions of `podman run`.

Q: Can I still use checkpoint and restore after patching?

Yes, through `podman container restore`. The fix removed checkpoint handling from `podman run` specifically, not from Podman's checkpoint feature overall.

Q: Do I need to change anything besides upgrading Podman?

Not strictly, but it's worth confirming any automation that runs images as root isn't pulling from untrusted registries, since that's the actual exposure path this bug needs. **Quick Summary:** - CVE-2026-94603 lets a crafted image disable your sandbox flags by faking a `io.podman.annotations.checkpoint.runtime.name` checkpoint annotation. - Affects Podman `>=4.4.0, =6.0.0, <6.1.3`; fixed in `5.8.8` and `6.1.3`. - Rootless Podman is not affected. Checkpoint and restore needs CRIU privileges rootless mode doesn't have. - NVD scores it 10.0 (Critical). Red Hat scores it 8.6 (Important) based on a local, user-interaction-required attack path. Both describe the same flaw. - The fix removed checkpoint-image support from `podman run` entirely rather than patching the annotation check. The underlying lesson from this podman checkpoint bypass isn't just "upgrade." Any feature allowed to override your explicit security flags needs its trust boundary checked, not just its presence flag. Run `podman version`. Patch to 5.8.8 or 6.1.3 if you're rootful. And if you haven't already moved your default workflows to rootless, this is a good reason to.

podman checkpoint annotation diagram showing a crafted image bypassing sandbox flags

If you run Podman in production, a container image can now disable the sandbox restrictions you explicitly asked for, just by carrying one annotation. CVE-2026-94603 is a podman checkpoint handling bug that tricks podman run into treating an ordinary image as a restored checkpoint, which silently overrides flags like --cap-drop=ALL. Here's exactly how the bypass works, who it actually reaches, and what you need to patch.

What Happened: A Crafted Image Can Turn Off Your Sandbox

Podman's run command is supposed to enforce whatever sandboxing flags you pass it. Run it with --cap-drop=ALL and you expect zero Linux capabilities inside that container, no exceptions.

CVE-2026-94603 breaks that guarantee. A container image carrying a specific annotation makes Podman treat your run command as if it were restoring a checkpoint instead of starting a fresh container. Checkpoint restores are allowed to bring their own capability set with them, so your flags get silently dropped. No error, no warning — the container just starts with weaker isolation than you asked for.

The Annotation Trick Behind the Podman Checkpoint Bug

The mechanism is narrow and specific, not a sprawling exploit chain. Podman has supported checkpoint and restore since version 4.4.0. It lets you snapshot a running container's process state, including open file descriptors, memory, and capabilities. You can restore that snapshot later, even on a different host. Podman identifies a checkpoint image by the io.podman.annotations.checkpoint.runtime.name annotation baked into the image's OCI metadata.

The bug is that podman run never verified the image actually came from a real podman container checkpoint export. It only checked for the annotation's presence. So an attacker can take any ordinary image and add that one annotation. Running podman run against that image then skips your sandboxing flags. It applies whatever capability set the fake checkpoint metadata specifies instead. One annotation, no memory corruption, no privilege escalation chain — just a trust check that assumed only genuine checkpoints would ever carry that label.

Why Podman Checkpoint Restores Get Special Treatment

This isn't an arbitrary design flaw. Checkpoint and restore has a real reason to behave differently from a normal run. When you restore a checkpoint, you're not starting a fresh container — you're resuming a process that was already running with a specific set of capabilities, namespaces, and open resources. If Podman forced your current command-line flags onto a restored process, the restore would frequently fail or behave in ways the original workload never expected.

So checkpoint restores have always been allowed to carry their own privilege configuration, overriding whatever you pass on the command line. That's reasonable when the checkpoint data is genuinely trustworthy. The gap was that podman run had no way to distinguish a real checkpoint from an image someone simply labeled to look like one.

Who's Exposed: Rootful Podman Only

This is scoped tighter than the headlines suggest. Checkpoint and restore depends on CRIU (Checkpoint/Restore In Userspace), a Linux feature that needs privileges rootless containers don't have access to. Both Red Hat's CVE record and the GitHub security advisory behind it confirm the same thing directly. Rootless containers are not affected, because checkpoint and restore is unavailable in that mode.

So if you're already running Podman rootless, this bug doesn't reach you at all. That's been the project's recommended default for years, because a compromised container only affects that user's own privileges. It's specifically a rootful-Podman problem — anyone running podman as root, including CI runners, build servers, and any workflow that pulls untrusted images with elevated privileges.

The CVSS Score Depends on Who You Ask

This part is worth being precise about, because the sources genuinely disagree, and you should know why rather than just picking a number. NVD's record is sourced from the GitHub Security Advisory the Podman maintainers filed. It scores this CVSS 3.1 10.0 (Critical), vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. That's a network attack vector, no privileges needed, no user interaction required.

Red Hat's own CVE record scores it lower, 8.6 (Important), vector AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. Red Hat models the attack vector as local rather than network, and it requires user interaction. That matches the exploitation path both advisories describe. An attacker has to entice someone into running a specially crafted image. That's a local action, not a remote, zero-interaction network attack.

Both scores describe the same flaw; they disagree on how to model the attack vector. Red Hat's local, interaction-required framing better matches how you'd actually get hit in practice. But don't let the lower number talk you out of patching — a full capability-set bypass on a container you expected to be locked down is serious under either score.

Affected Versions and What the Fix Actually Changed

CVE-2026-94603 affects Podman >=4.4.0, <5.8.8 and >=6.0.0, <6.1.3. It's fixed in 5.8.8 and 6.1.3.

The fix isn't a patched validation check. Maintainers removed checkpoint-image support from podman run entirely instead. The fix commit explains the reasoning directly: checkpoints are an extremely privileged operation that podman run was never built to constrain. So Podman now rejects any checkpoint-annotated image passed to run outright. The error is generated server-side during spec processing, instead of the old client-side check this bug exploited. That closes the whole bypass category, not just the one annotation.

Checkpoint and restore itself still works after the fix, just through podman container restore, which is a deliberate, audited operation instead of something a run command can be tricked into.

How to Check Your Podman Checkpoint Exposure and Patch

Run podman version and compare it against the ranges above. If you're anywhere from 4.4.0 through 5.8.7, or 6.0.0 through 6.1.2, and you run Podman rootful, you're exposed. Upgrade to 5.8.8 or 6.1.3, whichever major line you track, and the checkpoint-annotation bypass goes away because the feature it relied on no longer exists in podman run.

If you can't patch immediately, the practical mitigation is the same advice Podman has given for years: don't run untrusted images as root. Pair that with runtime detection. A tool like Falco can flag containers that start with an unexpected capability set. That catches this kind of silent sandbox downgrade even before you patch. Pinning digests and avoiding arbitrary registry images with elevated privileges are good general habits too. Our Docker best practices guide covers these, and most of it applies just as directly to Podman.

Frequently Asked Questions

Q: Does CVE-2026-94603 affect rootless Podman?
A: No. Both Red Hat's advisory and the GitHub security advisory confirm rootless containers aren't affected, because checkpoint and restore requires CRIU privileges that rootless mode doesn't have.

Q: What's the real CVSS score for this podman checkpoint bug?
A: Sources disagree. NVD lists 10.0 (Critical) based on the GitHub advisory's network/no-interaction scoring. Red Hat lists 8.6 (Important), scoring the attack vector as local with required user interaction, which matches how the bug is actually triggered.

Q: What annotation triggers the bypass?
A: io.podman.annotations.checkpoint.runtime.name. Any image carrying it gets treated as a checkpoint restore by vulnerable versions of podman run.

Q: Can I still use checkpoint and restore after patching?
A: Yes, through podman container restore. The fix removed checkpoint handling from podman run specifically, not from Podman's checkpoint feature overall.

Q: Do I need to change anything besides upgrading Podman?
A: Not strictly, but it's worth confirming any automation that runs images as root isn't pulling from untrusted registries, since that's the actual exposure path this bug needs.

Quick Summary:
- CVE-2026-94603 lets a crafted image disable your sandbox flags by faking a io.podman.annotations.checkpoint.runtime.name checkpoint annotation.
- Affects Podman >=4.4.0, <5.8.8 and >=6.0.0, <6.1.3; fixed in 5.8.8 and 6.1.3.
- Rootless Podman is not affected. Checkpoint and restore needs CRIU privileges rootless mode doesn't have.
- NVD scores it 10.0 (Critical). Red Hat scores it 8.6 (Important) based on a local, user-interaction-required attack path. Both describe the same flaw.
- The fix removed checkpoint-image support from podman run entirely rather than patching the annotation check.

The underlying lesson from this podman checkpoint bypass isn't just "upgrade." Any feature allowed to override your explicit security flags needs its trust boundary checked, not just its presence flag. Run podman version. Patch to 5.8.8 or 6.1.3 if you're rootful. And if you haven't already moved your default workflows to rootless, this is a good reason to.

DevToolHub