Go Github.com/containers/podman/v2 vulnerabilities
🔔 Create alert RSS Version checker
Published CVEs affecting Go Github.com/containers/podman/v2: 3 record(s), with affected versions and fixes.
CVE-2026-57231
High · 7.5
CWE-200 Jun 26, 2026
Podman: Malformed Image can trick podman run into leaking host environment variables into the container
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.
CVE-2024-9407
Medium · 4.7
CWE-20 Oct 1, 2024
Buildah: podman: improper input validation in bind-propagation option of dockerfile run --mount instruction
A vulnerability exists in the bind-propagation option of the Dockerfile RUN --mount instruction. The system does not properly validate the input passed to this option, allowing users to pass arbitrary parameters to the mount instruction. This issue can be exploited to mount sensitive directories from the host into a container during the build process and, in some cases, modify the contents of those mounted files. Even if SELinux is used, this vulnerability can bypass its protection by allowing the source directory to be relabeled to give the container access to host files.
CVE-2024-3056
High · 7.7
CWE-400 Aug 2, 2024
Podman: kernel: containers in shared ipc namespace are vulnerable to denial of service attack
A flaw was found in Podman. This issue may allow an attacker to create a specially crafted container that, when configured to share the same IPC with at least one other container, can create a large number of IPC resources in /dev/shm. The malicious container will continue to exhaust resources until it is out-of-memory (OOM) killed. While the malicious container's cgroup will be removed, the IPC resources it created are not. Those resources 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, such as `podman run --restart=always`, this can result in a memory-based denial of service of the system.