Overview
Kyverno, versions 1.16.0 to present, contains an SSRF vulnerability in its CEL-based HTTP functions, which lack URL validation or namespace scoping and allow namespaced policies to trigger arbitrary internal HTTP requests. An attacker with only namespace-level permissions can exploit this to access sensitive internal services via the highly privileged Kyverno admission controller.
Description
Kyverno is an open-source, Kubernetes-native policy engine that functions as a dynamic admission controller for the Kubernetes API. It is designed to manage the lifecycle of cluster resources by validating, mutating, and generating configurations based on YAML-defined policies. Within a security context, the engine is frequently utilized to enforce Pod Security Standards, verify image signatures via Cosign, and audit resource configurations for compliance. Because Kyverno operates with high-level permissions to intercept and modify API requests, it represents a critical component of the cluster’s security posture and trust boundary.
A server-side request forgery vulnerability exists in Kyverno’s CEL-based HTTP functions (Get and Post) used by namespaced policy types in the policies.kyverno.io API group. Unlike Kyverno’s resource library, which enforces namespace boundaries, the HTTP library at pkg/cel/libs/http/http.go performs no URL validation or scoping; i.e., there are no blocklists, namespace restrictions, or destination checks. As a result, these policies can issue arbitrary HTTP requests from the Kyverno admission controller pod.
Impact
An authenticated attacker with only namespace-scoped permissions can create a malicious namespaced policy that sends an internal http.Get() request, captures the response in a CEL variable, and exfiltrates it via the policy’s messageExpression field returned in the admission denial. Because requests originate from the Kyverno admission controller, which often has privileged network reachability across internal cluster services and cloud metadata APIs, this enables cross-namespace data access and potential exposure of sensitive metadata or service responses, effectively breaking Kyverno’s intended security boundaries through SSRF.
Solution
Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Since a patch is unavailable, we can only offer mitigation strategies.
Mitigation should include implementing strict URL validation and destination controls within Kyverno’s CEL HTTP library to ensure parity with the namespace-scoped restrictions enforced by the resource library. Recommended safeguards include blocking access to link-local and cloud metadata address ranges, limiting outbound requests to approved in-cluster services, and providing administrators with configurable allowlists. Additionally, applying default deny network policies to the Kyverno admission controller pod can reduce residual risk by preventing unauthorized egress in the event of future validation gaps.
Acknowledgements
Thanks to Igor Stepansky from Orca Security Research Pod for responsibly disclosing this vulnerability. This document was written by Dr. Elke Drennan, CISSP.
Vendor Information
Other Information
| CVE IDs: | |
| Date Public: | 2026-03-30 |
| Date First Published: | 2026-03-30 |
| Date Last Updated: | 2026-03-30 18:19 UTC |
| Document Revision: | 3 |
