CVE-2026-19730 in Podman
Summary
by MITRE • 08/13/2026
A flaw was found in Podman 5.8.x. The 'podman quadlet install --replace' command opens the existing destination file with O_CREATE|O_WRONLY but omits O_TRUNC. When the initial reflink copy attempt fails (common on non-reflink-capable filesystems including many RHEL default XFS configurations), the fallback in ReflinkOrCopy uses io.Copy which performs a non-truncating write. If the original Quadlet is larger than the new Quadlet, the file is not truncated and content from the original is preserved. The command completes with no warning.
There is no risk of information leakage as the user already had access to the Quadlet in order to replace it, and in most cases, this would only lead to invalid Quadlet files (see https://github.com/podman-container-tools/podman/issues/29013). However, security-related options from the end of the old Quadlet could be included in the new Quadlet, and if the truncation resulted in a valid Quadlet file, this could result in undesirable behavior. For example, running podman quadlet install --replace to remove a single line from the end of a Quadlet - including security-sensitive content, like AddCapability - will fail, and the option will continue to be used. Further, with Volume Quadlets, this can include additional mounts which can cause content to be unintentionally exposed into containers. If, later, the image is updated then compromised content might be leaked to an attacker.
The vulnerable code paths are in pkg/domain/infra/abi/quadlet.go (lines 338-360, O_CREATE|O_WRONLY without O_TRUNC) and vendor/go.podman.io/storage/pkg/fileutils/reflink_linux.go (lines 12-19, non-truncating io.Copy fallback).
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/13/2026
The vulnerability in Podman version 5.8.x affects the quadlet installation functionality when using the --replace flag, creating a persistent data integrity issue through improper file handling during replacement operations. This flaw exists in the core file manipulation logic where the system opens destination files with O_CREATE and O_WRONLY flags but deliberately omits the O_TRUNC flag, which is essential for ensuring that existing content is properly cleared before new data is written. The technical implementation follows a specific fallback mechanism designed to handle filesystems that do not support reflinking operations, particularly common on RHEL default XFS configurations where reflink operations fail regularly. When the initial reflink copy attempt fails, the system transitions to using io.Copy as a fallback method, which performs writes without truncating the existing file content.
The operational impact of this vulnerability manifests when users attempt to replace Quadlet files with smaller replacements, particularly those containing security-sensitive configuration options such as AddCapability directives or volume mount specifications. The lack of proper truncation means that remnants from the original larger Quadlet file persist in the destination, potentially leading to unintended behavior where deprecated or compromised settings continue to influence container operations even after what appears to be a successful replacement. This issue creates a potential attack surface where security-sensitive configurations could remain active unintentionally, especially when the truncated file still maintains syntactic validity but includes unwanted content from previous versions. The vulnerability directly relates to CWE-1283, which addresses improper truncation of files during replacement operations, and can be categorized under ATT&CK technique T1059.001 for execution through command-line interfaces.
The security implications extend beyond simple configuration persistence, particularly in environments where Quadlet files control critical container behaviors such as volume mounts, capability assignments, or access controls. When a user attempts to remove security-sensitive lines from a Quadlet file through the --replace command, these removed elements may persist due to the lack of truncation, creating potential vectors for privilege escalation or unauthorized access. The vulnerability becomes particularly concerning when dealing with Volume Quadlets that include mount specifications, as unintended content exposure could occur if old mount configurations remain in the replaced file. This scenario increases risk when images are subsequently updated, potentially causing compromised content to be inadvertently included in container runtime environments. The absence of warning messages during this process compounds the issue, as users remain unaware of the incomplete replacement operation.
Mitigation strategies should focus on implementing proper file truncation semantics in all file replacement operations within the Podman codebase, particularly in the quadlet installation module and related storage utilities. The immediate fix involves ensuring that when files are opened for replacement operations, the O_TRUNC flag is consistently included alongside O_CREATE and O_WRONLY flags to guarantee complete content replacement. Additionally, the fallback mechanism in the reflink implementation should be enhanced to explicitly truncate files before performing copy operations, regardless of whether the primary reflink method succeeds or fails. Organizations should implement monitoring for Quadlet file changes and validate the integrity of configuration files after any replacement operations to detect potential persistence of outdated configurations. The vulnerability demonstrates a classic case where filesystem compatibility assumptions lead to security-relevant implementation flaws, highlighting the importance of defensive programming practices in container management tools that handle sensitive system configurations.