CVE-2026-19730: Podman: podman: quadlet install --replace non-truncating write retains removed host-access directives
This is a vulnerability report sent to us through https://issues.redhat.com/browse/PSIRTSUPT-20013 and was created using the PoC auto-triage agents. It contains hints on the vulnerability extracted by the IA and the full report. ALWAYS review it before any action. Once working on this, don't forget to also update the JSM ticket.
A flaw was found in Podman 5.8.x. The 'podman quadlet install --replace' command opens the existing destination file with OCREATE|OWRONLY but omits OTRUNC. 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 replacement Quadlet file is shorter than the original, trailing bytes from the old file — including security-sensitive directives such as Volume= host-access mounts — survive in the installed unit file. The command returns success with no warning.
After a systemd daemon-reload or reboot, these stale directives reactivate host access the administrator explicitly revoked. A subsequent mutable-tag container image pull by an adversarial image can then exploit the retained host-access mounts to read secrets, modify files, or disrupt host services.
The vulnerable code paths are in pkg/domain/infra/abi/quadlet.go (lines 338-360, OCREATE|OWRONLY without OTRUNC) and vendor/go.podman.io/storage/pkg/fileutils/reflinklinux.go (lines 12-19, non-truncating io.Copy fallback).
Upstream fix: Podman 6.0/main branch introduced an atomic temp-file-plus-rename replacement pattern via PRs #28335 (merged 2026-06-05) and #28860 (merged 2026-06-25). The maintained 5.8 branch remains unpatched.
Mitigation: Administrators using 'podman quadlet install --replace' should manually verify the installed unit file contents after each replacement operation, and avoid using --replace with shorter replacement files until a fix is available. Alternatively, manually remove the destination file before running 'podman quadlet install' (without --replace).
Other sources
The 'podman quadlet install --replace' command opens the existing destination file with OCREATE|OWRONLY but omits OTRUNC. 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, OCREATE|OWRONLY without OTRUNC) and vendor/go.podman.io/storage/pkg/fileutils/reflinklinux.go (lines 12-19, non-truncating io.Copy fallback).
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Podmanto a version that resolves this vulnerability.Fixed in 6.0 - Configuration
Administrators should avoid using `podman quadlet install --replace` when the replacement Quadlet file is shorter than the original, since trailing bytes (e.g., host-access mounts/directives such as `Volume=`) can survive in the installed unit file.
Podman quadlet (podman quadlet install) podman quadlet install --replace behavior (non-truncating write) = Avoid using --replace with shorter replacement files until a fix is available - Configuration
After every `podman quadlet install --replace` operation, manually verify the installed unit file contents to ensure revoked host-access directives (e.g., host-access mounts) were not retained.
Podman quadlet install --replace Installed unit file contents verification = Verify after each replacement operation - Configuration
If needed to update a Quadlet without reactivating stale host-access directives, manually remove the destination file before running `podman quadlet install` (without `--replace`).
Podman quadlet install --replace option = Do not use --replace; manually remove destination file instead - Compensating control
After a systemd daemon-reload or reboot, stale Quadlet directives can reactivate host access that was explicitly revoked; review/verify the installed unit file contents after such events when using the vulnerable replacement workflow.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-19730?
CVE-2026-19730 has a medium severity rating of 4.2.
How do I fix CVE-2026-19730?
To address CVE-2026-19730, update Podman to a patched version that resolves this vulnerability.
What systems are affected by CVE-2026-19730?
CVE-2026-19730 affects Podman version 5.8.x when using the 'podman quadlet install --replace' command.
What are the potential impacts of CVE-2026-19730?
Exploitation of CVE-2026-19730 may result in the retention of removed host-access directives, leading to unintended access.
What is the nature of the flaw in CVE-2026-19730?
The flaw in CVE-2026-19730 involves the improper handling of file access flags, which leads to a failure in truncating files.