Podman run honoured an image's checkpoint annotation and dropped every sandbox restriction (CVE-2026-94603, vendor 10.0, Red Hat 8.6); fixed 5.8.8 and 6.1.3

View raw markdownEdit on GitHub ↗

TL;DR

From Podman 4.4.0, podman run treated an image carrying the io.podman.annotations.checkpoint.runtime.name annotation as a container checkpoint and restored it with the checkpoint's own settings, silently ignoring the caller's restrictions such as --cap-drop=ALL, so the image you pull decides how little sandboxing it runs with (CVE-2026-94603, GitHub CNA; vendor CVSS 3.1 10.0, Red Hat 8.6 Important). Fixed on 2026-09-29 in 5.8.8 and 6.1.3 by removing checkpoint-image support from podman run outright. Rootless Podman is not affected. Found by ADA Logics, credited "using Anthropic's Claude models." Vendor advisory 2026-09-29, CVE record 2026-10-13, advisory-database listing 2026-10-15; this file dates by the vendor. For this audience the exposure is any rootful host that runs an image chosen by untrusted content: a cloned repository's FROM line, an MCP tool that pulls an image, a CI job on a self-hosted runner.

What happened

The vendor advisory, GHSA-2cvf-wqm6-wr9g, published 2026-09-29 by maintainer mheon, explains the feature and the flaw. Podman 4.4.0 added distribution of container checkpoints through OCI registries, run with podman run. When podman run detected a checkpoint it ignored the user's container-creation options, capability restrictions included, and used the checkpoint's settings instead; it identified a checkpoint by one image annotation; and because a checkpoint fully controls the sandbox, an image could dictate how it ran. The maintainers removed the feature by reverting the introducing commits. The 5.8.8 release notes say the same in two lines: "Removed support for checkpoint images in podman run due to serious security concerns," and "Checkpoints ignore user-specified security configuration and are very difficult to run safely." The advisory's workaround for hosts that cannot upgrade is to scan pulled images for the checkpoint runtime annotation and reject any that carry it.

The CVE record (GitHub CNA, published 2026-10-13) lists >= 4.4.0, < 5.8.8 and >= 6.0.0, < 6.1.3, CVSS 3.1 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), six fix commits and the two release tags. Red Hat scores the same record 8.6 with vector AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H and rates it Important: running a malicious image bypasses expected confinement and can compromise host integrity, "exploitation requires an operator or automated workflow to launch an untrusted image," and environments that run only vetted images from trusted registries face reduced risk. The two vectors describe the same bug from two positions. The vendor scores the image as the network input and no user interaction, because the image arrives from a registry; Red Hat scores the podman run invocation as the local, user-initiated step. This file rates the advisory high: the restriction bypass is total and silent, but it needs rootful Podman and a run of an attacker-chosen image, and the rootless mode most developer laptops use is unaffected.

The relevance is the sandbox underneath the agent. Coding agents and sandbox products run untrusted work in containers and express their safety as the options they pass, --cap-drop, read-only mounts, no new privileges; this bug made those options advisory for any image that asked. The same month produced a Docker Sandboxes host escape through virtiofs symlinks and an opt-in-only fix in sandboxed.sh; the common lesson is that the sandbox's own configuration path is attack surface, and the image is part of that path.

Source note for the record: the repository has moved from github.com/containers/podman to github.com/podman-container-tools/podman; the CNA references and the vendor advisory URL use the new organisation, and the Go module paths in the advisory are still github.com/containers/podman and go.podman.io/podman/v6.

Am I affected?

podman --version                                     # 4.4.0 – 5.8.7 or 6.0.0 – 6.1.2 = affected range
podman info --format '{{.Host.Security.Rootless}}'   # true = not affected (checkpoint/restore unavailable rootless)
# The advisory's workaround check: does an image carry the checkpoint annotation?
podman image inspect IMAGE --format '{{index .Annotations "io.podman.annotations.checkpoint.runtime.name"}}'

Affected if a host in the range runs podman run as root on images it did not build, from registries it does not control, including images a coding agent or CI job selects from repository content.

If you are affected

Upgrade to 5.8.8 or 6.1.3 (or later), or run rootless. For the period a rootful host in the range ran images from untrusted sources, list the images it pulled and inspect them for the annotation; a hit means the container ran with the image's settings, not yours, and the host should be treated as compromised: rebuild it and rotate what it held, per rotating-cloud-credentials.md. Agent sandboxes built on Podman: confirm the version the sandbox ships, not only the host's.

Prevention

  • Run agent and CI containers rootless where the workload allows; this bug did not reach rootless Podman at all. See agent-sandboxing.md and ci-cd-hardening.md.
  • Pull images from registries you control, by digest; an image is input to the sandbox, not part of it.

Sources