Bug 2542566 (CVE-2026-94603)

Summary:	CVE-2026-94603 podman: podman: The `podman run` command can be instructed to disable almost all sandboxing - including user-requested sandboxing - by image annotation
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	akhatavk, aos-team-art-private, asdas, cdrage, dkeler, doconnor, dpaolell, dschmidt, ikhan, jdelft, jlanda, jupierce, kshier, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rbobbitt, rhel-process-autobot, rushinde, sdawley, security-response-team, sghai, sidsharm, simaishi, stcannon, suppawar, thason, vlaad, watson-tool-maintainers, yguenane
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in Podman. When a container image with checkpoint annotations is executed using the podman run command, Podman treats the image as a restored checkpoint and ignores user-specified sandboxing options, such as dropped privileges. An attacker can exploit this issue by enticing a user to run a specially crafted image, leading to a container sandbox bypass and potential execution with elevated system privileges.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2543275
Bug Blocks:
Deadline:	2026-09-30

Description OSIDB Bzimport 2026-09-28 16:54:23 UTC

Podman v4.4.0 added a feature where container checkpoints (from the podman container checkpoint command) could be distributed via OCI registry, and pulled from that registry and run via the podman run command. This allowed easy transfer of checkpoints between systems. However, checkpoints allow complete control of how the container is created - including full control of the container sandbox. When podman run detects a checkpoint, it will silently ignore all user input regarding how the container should be created - for example, podman run --cap-drop=ALL on an image that is determined to be a checkpoint will ignore --cap-drop=all and use the set of capabilities specified by the checkpoint image instead, which could include all capabilities. Podman identifies checkpoint images by looking for an annotation, io.podman.annotations.checkpoint.runtime.name. If this annotation is set, the image is treated as a checkpoint. Conflating container images and checkpoints in podman run allows inherently insecure behavior as the image can now control how it is executed. The Podman Maintainers have determined that the safest course of action is to remove this functionality.

Comment 3 Jon Orris 2026-10-22 13:28:40 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:88202 https://access.redhat.com/errata/RHSA-2026:88202