Database/Container, Kubernetes & orchestration

Kyverno: policy Service Call resolves external addresses and ships policy context off-cluster

CVE-2025-15613Container, Kubernetes & orchestrationcurated

Impact

Service Call is documented for reaching in-cluster services, but it also resolves external addresses, so a policy author can point it at a server they control. Kyverno sends policy context data with the request, and that context can include the contents of Kubernetes resources such as secrets - so this is a straightforward exfiltration channel rather than a probe. On a shared GPU cluster the secrets in reach are the ones that matter operationally: registry pull credentials, object-store keys for model and dataset buckets, and whatever the evaluated resources carry. This is the older of two Kyverno SSRF issues in this sweep; see also CVE-2026-84199, which adds the confused-deputy read-back path.

Who can reach it

Anyone with rights to create Kyverno (Cluster)Policy objects - typically a platform or tenant admin, not an unprivileged workload. Exfiltration additionally requires that the Kyverno pod can reach the attacker's host, so egress-restricted clusters blunt it.

What to do

Upgrade Kyverno to v1.13.4 or later. This rolls the admission controller Deployment - a daemon restart, no node drain or reboot - with a possible short admission gap if failurePolicy is Fail. Until the upgrade lands, restrict egress from the Kyverno namespace to in-cluster destinations and audit existing policies for apiCall/service entries pointing outside the cluster.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-15613 https://github.com/kyverno/kyverno/security/advisories/GHSA-459x-q9hg-4gpq https://www.vulncheck.com/advisories/kyverno-before-1.13.4-ssrf-via-service-call

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.