CVE-2026-4789: Kyverno SSRF Vulnerability

CVE-2026-4789 Overview

CVE-2026-4789 is a Server-Side Request Forgery (SSRF) vulnerability affecting Kyverno, a Kubernetes-native policy engine used for policy management, validation, and mutation of Kubernetes resources. Versions 1.16.0 and later are vulnerable due to unrestricted CEL (Common Expression Language) HTTP functions that allow attackers to craft malicious requests targeting internal services and infrastructure.

Critical Impact

This SSRF vulnerability enables attackers to bypass network security controls and access internal services, potentially leading to unauthorized access to cloud metadata services, internal APIs, and sensitive infrastructure components within Kubernetes clusters.

Affected Products

• Kyverno versions 1.16.0 and later
• Kubernetes clusters running vulnerable Kyverno deployments
• Cloud environments with Kyverno policy engines exposed to untrusted input

Discovery Timeline

• 2026-03-30 - CVE-2026-4789 published to NVD
• 2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-4789

Vulnerability Analysis

The vulnerability exists in Kyverno's implementation of CEL (Common Expression Language) HTTP functions. CEL is used within Kyverno to evaluate policy expressions, and the HTTP functions allow policies to make external HTTP requests. However, the unrestricted nature of these functions creates an SSRF attack surface.

Attackers can exploit this vulnerability by crafting policy expressions that leverage the CEL HTTP functions to make arbitrary HTTP requests. Since these requests originate from the Kyverno admission controller running inside the Kubernetes cluster, they can access internal services that would otherwise be protected from external access.

The vulnerability is particularly severe in cloud environments where instance metadata services (such as AWS IMDSv1 at 169.254.169.254, GCP metadata service, or Azure IMDS) can be accessed to retrieve sensitive credentials, API tokens, and configuration data.

Root Cause

The root cause of this vulnerability is the lack of proper URL validation and restriction on the CEL HTTP functions within Kyverno. The implementation fails to:

• Validate destination URLs against an allowlist of permitted endpoints
• Block requests to internal IP ranges (RFC 1918 addresses, link-local addresses)
• Prevent access to cloud provider metadata services
• Implement proper network segmentation controls for outbound HTTP requests

Attack Vector

The attack is network-based and can be executed without authentication or user interaction. An attacker with the ability to influence Kyverno policy expressions can:

1. Craft malicious CEL expressions containing HTTP function calls
2. Target internal Kubernetes services via their cluster DNS names or IP addresses
3. Access cloud metadata endpoints to steal IAM credentials or service account tokens
4. Pivot to other internal services using the Kyverno pod's network context
5. Exfiltrate sensitive data through response content or out-of-band channels

The vulnerability mechanism involves crafting CEL expressions that call HTTP functions with attacker-controlled URLs. When Kyverno evaluates these expressions, it makes HTTP requests from within the cluster's trusted network context, bypassing external firewall rules and network policies. For detailed technical analysis of SSRF attack patterns, refer to the PortSwigger SSRF Analysis documentation.

Detection Methods for CVE-2026-4789

Indicators of Compromise

• Unexpected outbound HTTP requests from Kyverno pods to internal IP addresses or metadata endpoints
• Kyverno policy configurations containing suspicious CEL expressions with HTTP function calls
• Audit logs showing access to cloud metadata services (e.g., 169.254.169.254) from Kyverno workloads
• Unusual network traffic patterns from the kyverno namespace to internal services

Detection Strategies

• Monitor Kubernetes audit logs for policy creation or modification events containing CEL HTTP function calls
• Implement network monitoring to detect requests from Kyverno pods to internal or metadata IP ranges
• Review Kyverno policy configurations for unexpected http.get(), http.post(), or similar CEL HTTP function usage
• Deploy runtime security tools to alert on abnormal network behavior from admission controller workloads

Monitoring Recommendations

• Enable verbose logging for Kyverno admission controller to capture policy evaluation details
• Configure network policies to log denied egress traffic from Kyverno pods
• Set up alerts for any traffic to cloud metadata endpoints (169.254.169.254, metadata.google.internal)
• Monitor for new or modified ClusterPolicy and Policy resources containing HTTP-related CEL functions

How to Mitigate CVE-2026-4789

Immediate Actions Required

• Audit all existing Kyverno policies for CEL expressions that use HTTP functions
• Review and restrict network policies for Kyverno pods to limit egress to only required destinations
• Block access to cloud metadata services from Kyverno pods using NetworkPolicy resources
• Consider temporarily disabling Kyverno if SSRF exploitation is suspected while investigating

Patch Information

Organizations should monitor the GitHub Kyverno Repository for security updates and patches addressing this vulnerability. Additionally, review the CERT Vulnerability Report #655822 for official guidance and remediation recommendations.

Workarounds

• Implement Kubernetes NetworkPolicy resources to restrict Kyverno pod egress to only trusted external endpoints
• Use IMDSv2 (hop limit enforcement) on AWS to mitigate metadata service access from container workloads
• Deploy a service mesh with egress controls to filter outbound HTTP requests from Kyverno
• Review and sanitize any user-controlled input that could influence CEL expression evaluation

# Example NetworkPolicy to restrict Kyverno egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: kyverno-egress-restriction
  namespace: kyverno
spec:
  podSelector:
    matchLabels:
      app: kyverno
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: TCP
      port: 443
  # Block metadata service access
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32
        - 10.0.0.0/8
        - 172.16.0.0/12
        - 192.168.0.0/16