GPU VulnDB

Database/Container, Kubernetes & orchestration

insights-runtime-extractor: incomplete privilege drop lets any pod get host root via its own argv[0]

CVSS 8.8CVE-2026-104795Container, Kubernetes & orchestrationcurated

Impact

The runtime-fingerprinting DaemonSet runs with hostPID and a hostPath-mounted CRI-O socket. To scan a workload it enters the target container's PID and mount namespaces and then drops privilege with seteuid() only - real UID and saved-set-UID stay 0 and the permitted capability set is retained - and the privilege guard is skipped entirely when the target container runs as uid 0. It then execs the workload's own binary, taken verbatim from the target's /proc/<pid>/cmdline argv[0], with --version. That binary can call setuid(0) to recover full root with CAP_SYS_ADMIN, and it inherits an orphaned working directory resolving into the extractor's filesystem where the host CRI-O socket is mounted. On a shared GPU cluster that means any tenant who can schedule an ordinary pod in any namespace gets root on the node and control of the container runtime - which is every GPU and every other tenant's workload on that host. CVSS scope is marked changed for exactly this reason.

Who can reach it

Any authenticated tenant able to schedule an unprivileged pod in any namespace on a cluster where the Insights runtime extractor DaemonSet is deployed. No cluster-admin, no privileged SecurityContext, and no interaction from the operator is required - the extractor comes to the pod on its scan cycle.

What to do

Apply the Red Hat update for the Insights runtime extractor / Red Hat OpenShift Container Platform 4 when it is available for your channel; check the Red Hat CVE page for the fixed build, as the record names no fixed version. Until then the containment is to remove the component: scale down or delete the insights-runtime-extractor DaemonSet (runtime workload fingerprinting is telemetry, not a control-plane dependency). Rolling the DaemonSet restarts only the extractor pods - no node drain and no GPU workload interruption.

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.