GPU VulnDB

Database/Container, Kubernetes & orchestration

Podman: podman machine init pulls VM images from an OCI registry without verifying the TLS certificate

CVE-2025-6032Container, Kubernetes & orchestrationcurated

Impact

An attacker positioned on the network path between the host and the OCI registry can substitute the VM disk image that podman machine init downloads, so the operator ends up booting an attacker-supplied machine image. The exposure is narrower than the container-runtime name suggests: only the podman machine VM path is affected, which is a developer and build-host workflow, not the rootful podman used to run containers directly on a Linux GPU node. It still matters at fleet scale because Red Hat shipped this in errata across RHEL 8, 9 and 10 and OpenShift Container Platform 4.16 through 4.18, so the podman package update lands on hosts throughout the estate. Running containers are not affected by the flaw itself.

Who can reach it

An attacker able to intercept or redirect the HTTPS connection from the host to the OCI registry - on-path on the network, or in control of DNS or a transparent proxy. No credentials are needed against Podman, but an operator has to actually run podman machine init for the flaw to be reached.

What to do

Apply the podman package update from the Red Hat errata listed in the record and re-provision any VM created by a prior podman machine init from an untrusted network, since an image already fetched is not retroactively validated. Podman is daemonless, so this is a package update on the affected hosts with no daemon restart, no node drain and no interruption to running containers.

References

Related entries

All Container, Kubernetes & orchestration entries

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.