GPU VulnDB

Database/Container, Kubernetes & orchestration

Kyverno: unvalidated ServiceCall URL turns the cluster-wide ServiceAccount into a confused deputy

CVE-2026-84199Container, Kubernetes & orchestrationcurated

Impact

The URL in a Policy's ServiceCall configuration is not validated, so a user who can create policies in a single namespace makes Kyverno issue arbitrary HTTP requests using its own cluster-wide, high-privilege ServiceAccount. The response comes back in the PolicyReport, which the same user can read - so this is not blind SSRF but a readable channel to other tenants' resources and to the node metadata endpoint at 169.254.169.254. On a GPU cluster where the namespace is the tenancy boundary, that is a tenant-to-cluster escalation: cloud IAM credentials from instance metadata typically reach model and dataset buckets and the registry, and other tenants' secrets include their own credentials. Nothing about the attack touches the GPU, but the blast radius is the whole fleet the credentials cover.

Who can reach it

Any user with namespace-level Kyverno Policy creation rights - a tenant admin in a delegated multi-tenant cluster, not a bare pod. No cluster-admin access needed, and no egress beyond what the Kyverno pod already has, since the metadata endpoint is link-local.

What to do

Upgrade Kyverno to 1.16.2 or later; this is a helm/operator upgrade that rolls the admission controller Deployment, so it costs a daemon restart and no node disruption. Watch for a brief admission gap during the rollout if failurePolicy is Fail. Interim mitigation until the window: deny link-local and off-cluster egress from the Kyverno pods with a NetworkPolicy, and restrict who can create (Cluster)Policy objects.

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.