Summary
Kyverno versions before 1.19.1 contain a server-side request forgery vulnerability in legacy external API call paths that do not enforce the platform's egress blocklist or scoped-token controls. An authorized policy or context author, and in some configurations a lower-privileged resource submitter, may cause Kyverno to send requests to cloud metadata services, loopback addresses, or internal cluster endpoints.
Affected context
The issue occurs in Kyverno deployments that use non-CEL context[].apiCall.service calls or the external-API path of GlobalContextEntry. These legacy paths use a general-purpose HTTP client without consistently validating destination URLs or applying egress restrictions. Risk depends on who can author policies or context entries and whether deployed policies derive service URLs from admission resources.
Exploit preconditions
- Attack surface: Kyverno policy-engine API call and GlobalContextEntry external-API execution paths
- Required access: Ability to create or modify a relevant ClusterPolicy or GlobalContextEntry; in some policy designs, ability to submit a resource that influences a templated service URL
- Trigger point: Evaluation of a configured non-CEL external API call
- Why exploitation is possible: The legacy executor accepts attacker-influenced destinations without applying the newer egress blocklist or equivalent URL validation and may attach Kyverno's projected ServiceAccount token to the request
Why this happens
The vulnerability results from inconsistent security controls between two HTTP request implementations. Egress filtering and scoped-token protections were integrated into the newer CEL HTTP library but were not applied to the legacy API call executor or the GlobalContextEntry external-API path. Because these paths use a plain HTTP client and do not sufficiently constrain destination URLs, untrusted or insufficiently trusted configuration can redirect Kyverno's network requests to arbitrary hosts. This behavior maps to CWE-918: Server-Side Request Forgery, where an application makes attacker-influenced server-side requests.
Potential impact
- Requests to cloud instance metadata services could expose temporary credentials
- Internal cluster services and loopback endpoints could be reached from Kyverno's network position
- Internal APIs may receive Kyverno's projected ServiceAccount token
- Sensitive responses from reachable services could be disclosed to policy evaluation or an attacker-controlled destination
- Network segmentation and service trust boundaries could be weakened
General mitigation guidance
Mitigation generally focuses on making outbound request destinations explicit, constrained, and independent of untrusted admission data.
Common defensive patterns include:
- Applying one consistent egress denylist and URL validation layer to every HTTP execution path
- Preferencing fixed, approved service destinations over resource-derived URLs
- Enforcing allowlists for schemes, hosts, ports, address ranges, redirects, and DNS resolution results
- Blocking cloud metadata, loopback, link-local, private, and otherwise unauthorized network ranges
- Avoiding automatic attachment of ServiceAccount tokens to arbitrary destinations
- Using narrowly scoped, audience-bound credentials only when a trusted destination requires them
- Running Kyverno with least-privilege network and Kubernetes permissions
- Applying network policies and egress gateways as defense-in-depth controls
How teams detect issues like this
Detection can combine source analysis, policy review, and runtime network monitoring.
- Static analysis can identify HTTP clients that consume policy- or admission-derived URLs without centralized SSRF validation.
- Code review can look for duplicated request paths, missing private-address checks, unrestricted redirects, and unconditional credential headers.
- Policy review can flag service URLs templated from resource fields or controlled by users with limited authorization.
- Runtime monitoring can alert on Kyverno connections to metadata addresses, loopback, private ranges, unexpected ports, or unapproved external hosts.
- Network and admission policies can enforce approved egress destinations and report denied connection attempts.
- Automated security review tools may help identify inconsistent safeguards across HTTP client implementations.
