On this page (7 sections)
Podman, the container engine used on many Linux servers and build hosts, has a critical flaw in how podman run handles certain images. If an image carries a specific annotation, Podman treats it as a checkpoint and silently ignores the restrictions you pass on the command line, including --cap-drop=ALL. The maintainers fixed it in Podman 5.8.8 and 6.1.3, as described in the GitHub advisory.
Anyone who runs images they did not build themselves with rootful Podman should care: hosting administrators, CI/CD owners, agencies and developers. At the time of writing, only one independent publisher (the advisory itself) covers this story, so the details below rest on that primary source.
What happened
Podman 4.4.0 added a way to distribute container checkpoints (created with podman container checkpoint) through an OCI registry and to start them with podman run. That made it easy to move checkpoints between systems.
The problem is that a checkpoint controls how the container is created, including its sandbox. According to the advisory, when podman run detects a checkpoint it silently ignores user input about how the container should be built. Running an image with --cap-drop=ALL would not drop anything if the image is a checkpoint; the capabilities stored in the checkpoint are used instead, and those could be the full set.
Podman recognizes a checkpoint by one annotation: io.podman.annotations.checkpoint.runtime.name. If it is present, the image is treated as a checkpoint. In plain terms, an ordinary-looking image can set its own security rules, overriding the ones the operator asked for.
Why this matters
The weakness class is a protection mechanism failure. Flags such as --cap-drop are how operators narrow what a container can do. If the image can override them without any warning, the operator believes a restriction is in place when it is not. The advisory scores the scope as changed with high confidentiality, integrity and availability impact.
The advisory's CVSS vector lists network attack vector, no privileges and no user interaction. In practice, an attacker still needs a victim to pull and run a crafted image, so your exposure depends on where your images come from. The advisory gives an EPSS score of 0.532% (45th percentile), an estimate of exploitation probability over 30 days.
Who is affected
- Hosts running Podman from 4.4.0 up to but not including 5.8.8.
- Hosts running Podman 6.0.0 up to but not including 6.1.3.
- Rootful containers only. The advisory states rootless containers are not affected because checkpoint and restore are not currently supported in that mode.
Highest risk: shared build servers, CI runners, hosting platforms and any system that pulls third-party or user-supplied images and runs them as root. Lower risk: hosts that only run images you build and pin yourself.
How to check your exposure
First find the installed version. This read-only command prints the Podman version; compare it with the fixed releases 5.8.8 and 6.1.3.
podman --versionTo see whether a specific image carries the checkpoint annotation, inspect its metadata. This read-only command prints the image's metadata and filters for the annotation name io.podman.annotations.checkpoint.runtime.name. Replace IMAGE with the image reference. Where the annotation is stored can vary by image format, so treat an empty result as a hint, not proof.
podman image inspect IMAGE | grep -i checkpoint.runtime.nameAlso check whether any containers run as root (rootful) on the host, since those are the ones in scope. This read-only command lists all containers owned by root.
sudo podman ps -aWhat to do now
The fix removes the functionality. The maintainers concluded that the safest course was to revert the commit that introduced it, so there is no setting to enable afterwards. The fixed releases are v5.8.8 and v6.1.3.
0 of 7 done
The advisory's only workaround is to scan pulled images for the annotation and reject any that have it. It states that Podman cannot yet do this scanning and rejection automatically, so you would need to add it to your own image intake or CI process.
Detection and monitoring
- Add an image-intake check in CI that fails when the checkpoint annotation is present.
- Audit which images your rootful hosts have pulled recently and from which registries.
- Look for containers running with broader capabilities than your run commands specify. A mismatch between the flags you passed and the container's real capabilities is a warning sign.
- Keep a software inventory with Podman versions so the next advisory takes minutes to assess.
The advisory does not describe any observed attacks, and nothing in the provided records points to exploitation in the wild. That can change, so keep watching the advisory and your distribution's security feed.
If you also run public websites on these hosts, outside checks help catch side effects of a compromised server, such as changed pages or certificates. The Webforta Monitor service watches for certificate, DNS and header changes, and the free malware scanner gives a quick outside view. These do not see inside your containers and do not replace patching.
Timeline
| Date | Event |
|---|---|
| Sep 29, 2026 | Advisory published in the podman-container-tools/podman repository |
| Oct 13, 2026 | Published by the National Vulnerability Database |
| Oct 15, 2026 | Published to the GitHub Advisory Database, reviewed and last updated |
The advisory credits ADA Logics Ltd with discovering the flaw using Anthropic's Claude models. For more background, browse the security guides hub.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.