CVE-2026-19730

Description

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

Statement

CVSS scope note: Reporter (Christopher Lusk) initially scored this Scope Changed (S:C), reasoning that a later compromise or mutable-tag overwrite of the container image could exploit the retained host mount/capability to reach host resources. Upstream maintainer Paul Holzinger (Podman) scored it Scope Unchanged (S:U), noting that this secondary compromise is a separate event the flaw does not itself grant or enable — the flaw's own effect is that Podman fails to enforce a configuration change (a directive removal) that the administrator, via Podman, already had full authority over. Scoped to what the flaw itself contributes, no security authority beyond Podman/the administrator's own control is crossed, so Scope Unchanged is the more accurate classification.

Resolved vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L (~4.2, Moderate)

Mitigation

Patches available at https://github.com/podman-container-tools/podman/commit/a38a9b7d20915c55e6f3c451101ae72d6da33742 for versions 5.8.6 and 6.0.0.

If patches cannot be used, possible workarounds are to manually copy the quadlet files to the quadlet directory or remove the destination file before running 'podman quadlet install' (without --replace).

Common Vulnerability Scoring System (CVSS) Score Details

Info alert:Important note

CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).

The following CVSS metrics and score provided are preliminary and subject to review.

CVSS v3 Score Breakdown

Red HatNVDcve.org
Base Score4.2N/A4.2
Attack VectorLocalN/ALocal
Attack ComplexityHighN/AHigh
Privileges RequiredLowN/ALow
User InteractionRequiredN/ARequired
ScopeUnchangedN/AUnchanged
ConfidentialityLowN/ALow
Integrity ImpactLowN/ALow
Availability ImpactLowN/ALow

Vector

Red Hat: CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L

cve.org: CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L

Red Hat CVSS v3 Score Explanation

Reflects reporter's revised assessment (corrected 2026-07-20 from an initial 7.5) after review with Podman upstream: the flaw only extends how long an already-revoked host mount stays active, it doesn't independently grant new capability to a compromised image.

Understanding the Weakness (CWE)

Other,Confidentiality,Integrity

Technical Impact: Other; Read Application Data; Modify Application Data; DoS: Resource Consumption (Other)

It is possible to overflow the number of temporary files because directories typically have limits on the number of files allowed. This could create a denial of service problem.

Acknowledgements

Red Hat would like to thank Christopher Lusk (North Echo Security Research) and Paul Holzinger (Podman) for reporting this issue.

Frequently Asked Questions

Want to get errata notifications? Sign up here.