GPU VulnDB

Database/Container, Kubernetes & orchestration

Podman: files written to bind mounts during build persist in the host build context directory

CVE-2025-4953Container, Kubernetes & orchestrationcurated

Impact

Data written inside a container to a RUN --mount=type=bind mount during podman build is not discarded when the build step ends; it lands in the temporary build context directory on the host and stays readable there. A Containerfile from an untrusted source can therefore drop files onto the build host, and content that was meant to exist only inside a build layer can leak to whoever can read that directory. On a fleet where image builds run on shared or GPU-equipped build nodes, this means build inputs and secrets handled during a build are exposed beyond the build sandbox. The impact is confined to the machine performing the build, not to running workloads.

Who can reach it

Anyone who can get a Containerfile built by your Podman build host, plus any local user able to read the temporary build context directory on that host. No authentication to the container is needed beyond the ability to submit a build.

What to do

Update Podman/Buildah from the Red Hat errata for your RHEL or OpenShift stream; the fix takes effect for new builds, so no reboot is needed - restart or re-run build jobs after the package update. Until then, treat build hosts as sensitive: run builds in disposable VMs or pods and clear temporary build context directories after each build.

References

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.