CISA issues guidance on SSRF in Kyverno CEL HTTP functions
31st article in the last 90 days, one of 530 articles referencing Cybersecurity and Infrastructure Security Agency (CISA). Previous coverage: CISA updates CrewAI alert on SSRF, RCE, and file read (Mar 2026).
Companies mentioned
Best suited for
- Seniority
- C Level / Executive Team
- Job function
- Chief Information Security Officer
- Persona
- Security Operations Leader
- Buyer role
- Decision Maker / Budget Holder
- Decision stage
- Which to buy
- Adoption curve
- Late Majority
- Technology maturity
- Market Correction
- Industry
- Information Technology / Software & Services / IT Services / Cloud Services
Our classification, not the publisher's statement. Best suited for, not only for.
Kyverno versions 1.16.0 to present have a server-side request forgery weakness in their CEL-based Hypertext Transfer Protocol (HTTP) functions, which can let namespaced policies trigger arbitrary internal HTTP requests. The highest-level impact described is cross-namespace data access and exposure of sensitive internal service responses or metadata from requests issued by the Kyverno admission controller.
The issue is tied to Kyverno’s CEL-based HTTP functions, specifically Get and Post, used by namespaced policy types in the policies.kyverno.IO Application Programming Interface (API) group. The HTTP library located at pkg/cel/libs/http/http.go performs no URL validation or scoping, meaning there are no blocklists, namespace restrictions, or destination checks. As stated, unlike Kyverno’s resource library, which enforces namespace boundaries, these policies can issue arbitrary HTTP requests from the Kyverno admission controller pod. The advisory also identifies CVE-2026-4789.
According to the advisory, an authenticated attacker with only namespace-scoped permissions can create a malicious namespaced policy that sends an internal http.Get() request, stores the response in a CEL variable, and exfiltrates it through the policy’s messageExpression field returned in the admission denial.
The document states that a patch is unavailable and also describes an inability to reach the vendor to coordinate the vulnerability. It advises mitigation by 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. It further recommends blocking access to link-local and cloud metadata address ranges, limiting outbound requests to approved in-cluster services, providing administrators with configurable allowlists, and applying default deny network policies to the Kyverno admission controller pod.
The guidance repeats that mitigation should include strict URL validation and destination controls in the CEL HTTP library, along with safeguards that block link-local and cloud metadata address ranges and limit outbound requests to approved in-cluster services using administrator-configurable allowlists. It also includes applying default deny network policies to the Kyverno admission controller pod to reduce residual risk in the event of future validation gaps.
Blog post, originally published at kb.cert.org.