GPU VulnDB

Database/Container, Kubernetes & orchestration

Kyverno: APICall URLPath query string defeats the namespace regex, reading cluster-scoped resources

CVSS 8.3CVE-2026-122312Container, Kubernetes & orchestrationcurated

Impact

path.Clean treats '?' as an ordinary path character, so the namespace regex that is meant to confine a namespaced policy's APICall can be satisfied by a segment inside the query string while client-go actually requests the cluster-scoped endpoint. A tenant who can create namespaced policies can therefore read resources outside their namespace through Kyverno's service account - node objects, and whatever else that account can list. On a multi-tenant GPU cluster that is a cross-tenant read: node inventory and labels reveal GPU topology and placement, and other namespaces' objects may carry configuration a tenant should not see. The read runs with Kyverno's privileges, not the tenant's, which is what makes a namespaced policy author dangerous here.

Who can reach it

Any authenticated tenant with create rights on namespaced Kyverno policies that use APICall. Authentication required; no cluster-scoped read rights of their own.

What to do

Upgrade Kyverno to 1.19.2 or later (only 1.19.1 is affected) and restart the Kyverno pods; the fix is commit f67231d. Interim: restrict who may create namespaced policies containing APICall context entries, and consider trimming the Kyverno service account's cluster-wide read permissions. Control-plane only.

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.