The cbismanager Podman container is vulnerable to remote command execution via the /api/plugins endpoint. Improper sanitization of the HTTP Headers X-FILENAME, X-PAGE, and X-FIELD allows for command injection. These headers are directly utilized within the subprocess.Popen Python function without adequate validation, enabling a remote attacker to execute arbitrary commands on the underlying system by crafting malicious header values within an HTTP request to the affected endpoint. The web service executes with root privileges within the container environment, the demonstrated remote code execution permits an attacker to acquire elevated privileges for the command execution. Restricting access to the management network with an external firewall can partially mitigate this risk.

Impact The podman machine init command fails to verify the TLS certificate when downloading the VM images from an OCI registry (which it does by default since 5.0.0) allowing a possible Man In The Middle attack.

Patches https://github.com/containers/podman/commit/726b506acc8a00d99f1a3a1357ecf619a1f798c3 Fixed in v5.5.2

Workarounds Download the disk image manually via some other tool that verifies the TLS connection. Then pass the local image as file path (podman machine init --image ./somepath)

Podman is a tool for managing OCI containers and pods. From 1.8.1 until 5.8.4, a container image that contains a environment variable with just a key and no value can trick podman into passing that variable from the host into the container. This is made worse by the fact that using an asterisk () will cause podman to pass all host variables into the container. So essentially a malicious image can exfiltrate all podman environment variables that are set in the session from where the container is launched. This vulnerability is fixed in 5.8.4 and 6.0.0.

The podman kube play command can overwrite host files when the kube file contains a ConfigMap or Secret volume mount and the volume already contains a symlink to a host file. This allows a malicious container to write to arbitrary files on the host but the attacker only controls the target path not the contents that will be written to file. The contents are defined in the yaml file by the end user.

Podman is a tool for managing OCI containers and pods. Versions 4.8.0 through 5.8.1 contain a command injection vulnerability in the HyperV machine backend in pkg/machine/hyperv/stubber.go, where the VM image path is inserted into a PowerShell double-quoted string without sanitization, allowing $() subexpression injection. Because PowerShell evaluates subexpressions inside double-quoted strings before executing the outer command, an attacker who can control the VM image path through a crafted machine name or image directory can execute arbitrary PowerShell commands with the privileges of the Podman process. On typical Windows installations this means SYSTEM-level code execution, and only Windows is affected as the code is exclusive to the HyperV backend. This issue has been patched in version 5.8.2.

Podman is a tool for managing OCI containers and pods. From 1.8.1 until 5.8.4, a container image that contains a environment variable with just a key and no value can trick podman into passing that variable from the host into the container. This is made worse by the fact that using an asterisk () will cause podman to pass all host variables into the container. So essentially a malicious image can exfiltrate all podman environment variables that are set in the session from where the container is launched. This vulnerability is fixed in 5.8.4 and 6.0.0.

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

Summary: We received a report of an attack vector on containers which share an IPC namespace (definitely Podman, but likely also applicable to Kubernetes, Docker, and other container runtimes). At least two containers are configured with a shared IPC namespace and a cgroup limiting memory. One of those containers is malicious, and contains a binary which creates a large number of IPC resources in /dev/shm, and continues doing so until it is OOM killed. The malicious container is now dead, its cgroup removed, but the IPC resources it created are not; they are tied to the IPC namespace that will not be removed until all containers using it are stopped, and one non-malicious container is holding the namespace open. The malicious container is restarted (either automatically or by attacker control), repeating the process and increasing the amount of memory consumed. With a container configured to restart always (e.g. podman run --restart=always) this results in a memory-based denial of service of the system.

Podman Version: Version 5.0.0-dev and before

A flaw in the containers/common Go library, used by container runtimes such as Podman, Buildah, and CRI-O, allows a malicious container image to exploit the FIPS mode to bind mount arbitrary host directories into the container. The flaw arises from the MountsWithUIDGID() function, which attempts to mount a FIPS-related directory inside the container but does not properly verify the path. If the FIPS path is a symlink, it could point to arbitrary directories on the host, allowing an attacker to access sensitive host files.

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

An incorrect handling of the supplementary groups in the Podman container engine might lead to the sensitive information disclosure or possible data modification if an attacker has direct access to the affected container where supplementary groups are used to set access permissions and is able to execute a binary code in that container.

Reference:

https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/

podman incorrectly allows containers, when created, to populate volumes that already have existing data inside. A malicious container image may use this flaw to overwrite existing files in a volume, even if it is mounted in read-only mode. The attack is possible only the first time a volume is used.