--- id: 2026-10-podman-run-checkpoint-annotation-disables-sandboxing-cve-2026-94603 title: "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" date_disclosed: 2026-09-29 last_updated: 2026-10-16 severity: high status: patched ecosystems: [containers, agent-sandboxing, linux, go] tools_affected: ["Podman 4.4.0 through 5.8.7 and 6.0.0 through 6.1.2, rootful `podman run` only", "agent sandboxes, CI runners and build hosts that run images they did not build with rootful Podman", "rootless Podman: not affected, checkpoint and restore are unavailable there"] tags: [cve, podman, container, sandbox-bypass, checkpoint, image-annotation, agent-sandboxing, capabilities, ada-logics, claude-assisted-finding, vendor-ghsa, database-backfill, score-disagreement, patched] --- ## 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](2026-09-docker-sandboxes-virtiofs-symlink-host-escape.md) and [an opt-in-only fix in sandboxed.sh](2026-10-continue-cli-bash-rule-chaining-bypass-vulncheck-agent-sandbox-batch.md); 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? ```bash 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](../playbooks/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](../prevention/agent-sandboxing.md) and [ci-cd-hardening.md](../prevention/ci-cd-hardening.md). - Pull images from registries you control, by digest; an image is input to the sandbox, not part of it. ## Sources - [GHSA-2cvf-wqm6-wr9g, Podman vendor advisory](https://github.com/podman-container-tools/podman/security/advisories/GHSA-2cvf-wqm6-wr9g) — 2026-09-29, mechanism, patched versions, workaround, credit to ADA Logics "using Anthropic's Claude models." - [CVE-2026-94603, CVE Services record (GitHub CNA)](https://cveawg.mitre.org/api/cve/CVE-2026-94603) — published 2026-10-13, ranges, 10.0 vector, fix commits and release tags. - [Podman v5.8.8 release](https://github.com/podman-container-tools/podman/releases/tag/v5.8.8) — 29 Sep, "addresses CVE-2026-94603," the breaking-change lines. - [Red Hat CVE-2026-94603](https://access.redhat.com/security/cve/CVE-2026-94603) — 8.6, local vector with user interaction, Important, the statement on untrusted images. - [GitHub Advisory Database, query "claude"](https://github.com/advisories?query=claude+sort%3Apublished-desc) — the 2026-10-15 listing row that surfaced the record, through the credit line.