Podman is the daemonless container engine that Linux administrators, developers and CI/CD systems use to build, pull and run OCI images. In GHSA-2cvf-wqm6-wr9g, a feature intended to move container checkpoints through OCI registries turned an image into authority over its own launch-time isolation. That matters most to organisations that automate rootful Podman runs from registries: platform teams, Red Hat-oriented enterprise estates, build farms and operators of containerised services.
A checkpoint is not an ordinary image. It is a saved running-container state, including details needed to recreate its sandbox. Starting with Podman 4.4.0, podman run inspected an image annotation named io.podman.annotations.checkpoint.runtime.name; if present, it treated the pulled artifact as a checkpoint and restored it. The maintainers' advisory says that restoration used the checkpoint's recorded security context and silently ignored command-line controls such as --cap-drop=ALL.
An annotation could replace the operator's policy
An attacker first needs an operator or automated workflow to pull and launch an attacker-controlled image or checkpoint with rootful Podman. They do not need credentials on the target under the upstream scoring model, but the practical prerequisite is consequential: somebody must run the untrusted artifact. Once that happens, a malicious checkpoint can specify the capabilities and sandbox settings the container receives rather than the restrictions the operator thought they imposed. That can yield code execution in a far less confined container and undermine the isolation boundary the launch command was meant to enforce.
The removed logic made the annotation alone select the restore path:
- // If this is a checkpoint image, restore it.
- img, resolvedImageName := opts.Spec.GetImage()
- if img != nil && resolvedImageName != "" {
- imgData, err := img.Inspect(ctx, nil)
- if err != nil {
- return nil, err
- }
- if imgData != nil {
- _, isCheckpointImage := imgData.Annotations[define.CheckpointAnnotationRuntimeName]
- if isCheckpointImage {
- var restoreOptions entities.RestoreOptionsNotice that this is a mode switch based on image-controlled metadata, not a validation of the user's requested runtime policy. Rootless containers are not affected because they do not support checkpoint/restore.
Upgrade, and treat checkpoints as a separate trust decision
A patch exists: Podman 5.8.8 and 6.1.3, both released September 29, 2026, remove checkpoint-image support from podman run; the 5.8.8 release documents that change. The affected upstream ranges are 4.4.0 through versions before 5.8.8, and 6.0.0 through versions before 6.1.3. Distribution packages may backport the change, so teams should verify their vendor's fixed build rather than comparing only the visible version string.
Until upgraded, inspect every artifact before launch and reject any carrying the checkpoint annotation. Podman cannot automatically perform that scan-and-reject step. Restrict who can publish to registries and what CI or operational workflows may pull and run; use rootless execution where it fits the workload. The follow-up revert restores a safer separation: checkpoint restoration belongs in the explicit podman container restore command, not ordinary image execution.
As of October 21, 2026, no exploitation in the wild, victims, campaign or public proof of concept had been confirmed. CVE-2026-94603 is not in CISA's Known Exploited Vulnerabilities catalogue, which means CISA has not catalogued known exploitation, not that exploitation is impossible. Inventory rootful Podman and its registry-driven launch paths now; SecAlerts monitors an organisation's actual software stack and alerts on new vulnerabilities affecting the products it runs.
