Description

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).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.2",
  "pubDate": "2026-08-13T18:17:25.330Z",
  "pubdate": "2026-08-13T18:17:25.330Z",
  "executiveSummary": "A file truncation vulnerability exists in Podman 5.8.x specifically within the 'podman quadlet install --replace' command. The vulnerability arises because the destination file is opened using O_CREATE and O_WRONLY flags while omitting the O_TRUNC flag. When a reflink copy attempt fails—a common occurrence on non-reflink-capable filesystems such as numerous default Red Hat Enterprise Linux (RHEL) XFS configurations—the fallback mechanism executes an io.Copy operation. This fallback performs a non-truncating write, causing leftover content from a larger original Quadlet to persist if the replacement Quadlet is smaller.\nThe impact of this flaw includes the preservation of residual configurations, potentially retaining security-related options from the end of the old Quadlet, such as AddCapability directives or unauthorized volume mounts. If these residual configurations result in a valid Quadlet file, it can lead to undesirable runtime behavior, unintended data exposure into containers, and potential exploitation vectors if container images are later updated and compromised content is leaked to an attacker.\nAttacker capabilities require local access to execute the Podman command and modify Quadlet files. No specialized network exposure or advanced privileges beyond those required to manage local Quadlet installations are necessary. Remediation relies on ensuring proper file truncation handling during the copy fallback phase within the affected codebase.",
  "technicalDetails": "The root cause of the vulnerability stems from improper file open flags and fallback copy logic in the Podman codebase. Specifically, the vulnerable code paths are located in pkg/domain/infra/abi/quadlet.go across lines 338 to 360, where the destination file is opened with O_CREATE and O_WRONLY but lacks O_TRUNC. Additionally, the vendor/go.podman.io/storage/pkg/fileutils/reflink_linux.go file contains the ReflinkOrCopy fallback implementation on lines 12 through 19, which relies on a non-truncating io.Copy operation.\nThe step-by-step attack flow begins when an authenticated local user executes the 'podman quadlet install --replace' command to replace an existing, larger Quadlet file with a smaller updated version. Because the target environment utilizes a non-reflink-capable filesystem (such as many default RHEL XFS configurations), the initial reflink copy operation fails. The execution flow automatically transitions to the ReflinkOrCopy fallback routine using io.Copy.\nBecause O_TRUNC was omitted when opening the destination file and io.Copy appends or overwrites only up to the size of the new input, any bytes residing past the end of the new Quadlet content from the original, larger file are preserved. If the resulting file structure remains syntactically valid, the Podman runtime parses and applies the stale trailing configurations. For instance, if an administrator attempts to remove a security-sensitive directive like AddCapability or an explicit volume mount from the end of the Quadlet, the operation fails to purge the option, causing it to remain persistently active.\nPost-exploitation impact manifests when volume Quadlets retain unintended additional mounts, leading to sensitive host content being exposed inside containers. If the container image is subsequently updated or interacted with by an attacker, the inadvertently exposed data can be leveraged to compromise the system or leak sensitive information. Authentication and privilege requirements are limited to local execution capabilities where the user already possesses authorization to manipulate Quadlet files."
}