Kyverno CVE-2025-15613

Exploitation requires the attacker to hold a Kubernetes RBAC binding granting create/update on the kyverno.io ClusterPolicy or Policy custom resources. This is not assigned to any built-in Kubernetes role and must be explicitly provisioned; it is most likely to exist in GitOps workflows, developer self-service platforms, or clusters where application teams are permitted to author their own admission policies. Once the malicious policy is placed, no further attacker action is needed: the SSRF fires automatically on every admission event for matching resources. Additional limiting factors: Kyverno's admission webhook must be active and the kyverno controller pod must have outbound network reachability to the attacker's server. The PR:N rating in the supplied CVSS 4.0 vector does not reflect these prerequisites and should not be used for risk-tiering decisions.

The supplied CVSS 4.0 vector (PR:N) conflicts directly with the CVE description, which states exploitation requires permission to create Kyverno (Cluster)Policies - a non-default RBAC grant that must be explicitly provisioned. PR:N is incorrect for this vulnerability; this analysis uses PR:L in the independent assessment. The CVSS 4.0 impact metrics (VI:L, SC:L, SI:L, SA:L) also underrepresent the actual confidentiality outcome: full Kubernetes Secret contents can be exfiltrated, which represents a high confidentiality impact. No EPSS score was provided, and no CISA KEV listing exists. Despite these gaps, the publicly documented PoC significantly raises the practical risk bar - any cluster where developers or CI/CD service accounts hold policy creation rights is directly threatened. The real-world risk concentrates in multi-tenant clusters and GitOps environments where policy authoring is delegated beyond the cluster-admin role; tightly RBAC-controlled clusters face substantially lower exposure.

An attacker who has obtained a developer or CI/CD service account with ClusterPolicy creation rights creates a malicious ClusterPolicy with an apiCall/service.url pointing to a Burp Collaborator or similar attacker-controlled HTTPS listener, scoped to match all ConfigMap or Secret resources. When any cluster user subsequently creates or updates a matching resource, Kyverno's admission webhook fires, the controller evaluates the policy, and the full resource context - including Secret data fields - is HTTP POSTed to the attacker's server. A working PoC demonstrating this exact flow against a live cluster was published in GHSA-459x-q9hg-4gpq.