CVE-2026-100705: Kyverno SSRF Vulnerability

CVE-2026-100705 Overview

CVE-2026-100705 is a Server-Side Request Forgery (SSRF) [CWE-918] vulnerability in Kyverno, a Kubernetes policy engine. Versions prior to 1.19.1 fail to apply the default egress blocklist and scoped-token controls to the legacy apiCall service executor and the GlobalContextEntry external-API path. A policy author, or a lower-privileged resource submitter when a deployed policy templates the service URL from the admission resource, can force Kyverno to issue arbitrary GET or POST requests. Reachable targets include cloud metadata endpoints, loopback addresses, and internal cluster services. The flaw is fixed in Kyverno 1.19.1.

Critical Impact
Attackers can read cloud instance credentials from metadata services (such as 169.254.169.254) and pivot to internal cluster endpoints using Kyverno's network position.

Affected Products

Kyverno versions prior to 1.19.1
Kyverno ClusterPolicy configurations using context[].apiCall.service
Kyverno GlobalContextEntry external-API path

Discovery Timeline

2026-09-26 - CVE-2026-100705 published to the National Vulnerability Database (NVD)
2026-09-28 - Last updated in NVD database

Technical Details for CVE-2026-100705

Vulnerability Analysis

Kyverno 1.19.0 introduced an egress blocklist and a scoped-token control to restrict outbound HTTP requests from policy executions. The blocklist blocks cloud metadata endpoints (169.254.169.254, 169.254.169.253, metadata.google.internal), loopback ranges (127.0.0.0/8, ::1/128), and related addresses. However, these controls were wired only into the new Common Expression Language (CEL) http.Get/http.Post library.

The legacy apiCall service executor at pkg/engine/apicall/executor.go and the GlobalContextEntry external-API path were never updated. Both paths continue to use a plain net/http client without egress filtering or validation of the configured service URL. Any policy that uses the non-CEL context[].apiCall.service field bypasses the intended controls entirely.

Root Cause

The root cause is incomplete security control coverage across code paths handling the same functionality. Security filtering was retrofitted to one HTTP execution path while two parallel legacy paths retained unrestricted outbound request capability. The executor also unconditionally attaches Kyverno's projected ServiceAccount token to attacker-chosen destinations, though the token's audience scoping limits replay value.

Attack Vector

An attacker with permissions to create or modify a ClusterPolicy or GlobalContextEntry can set the service.url field to a target such as http://169.254.169.254/latest/meta-data/iam/security-credentials/. When Kyverno processes an admission request matching the policy, it issues the HTTP request from inside the cluster and returns the response data to the policy context. Where a deployed policy templates the service URL from fields in the admission resource, a lower-privileged user who can submit matching resources can also trigger arbitrary requests. See the GitHub Security Advisory GHSA-q825-p383-r9v5 and the VulnCheck SSRF Advisory for additional technical details.

Detection Methods for CVE-2026-100705

Indicators of Compromise

Outbound HTTP connections from Kyverno pods to cloud metadata IPs including 169.254.169.254, 169.254.169.253, or metadata.google.internal.
Kyverno pod connections to loopback addresses or to in-cluster services that are not part of normal policy evaluation.
Newly created or modified ClusterPolicy or GlobalContextEntry resources containing apiCall.service.url values pointing to internal or metadata endpoints.

Detection Strategies

Audit Kubernetes API server logs for create and update operations on ClusterPolicy and GlobalContextEntry resources, flagging any service.url referencing link-local, loopback, or internal addresses.
Inspect network flow logs from Kyverno pods for destinations outside the expected set of policy data sources.
Review Kyverno engine logs for apiCall execution events referencing suspicious URLs or returning sensitive response payloads.

Monitoring Recommendations

Deploy Kubernetes NetworkPolicies that restrict egress from Kyverno pods to an allow-list of required destinations, and alert on policy denials.
Use a service mesh or egress gateway to centralize and log all outbound traffic from policy engine workloads.
Monitor cloud provider audit logs for Instance Metadata Service (IMDS) credential retrievals originating from node IPs hosting Kyverno pods.

How to Mitigate CVE-2026-100705

Immediate Actions Required

Upgrade Kyverno to version 1.19.1 or later across all clusters.
Enforce IMDSv2 with hop-limit 1 on AWS nodes, and equivalent metadata protections on GCP and Azure, so pod-level SSRF cannot reach instance credentials.
Audit existing ClusterPolicy and GlobalContextEntry resources for apiCall.service.url entries that reference internal, loopback, or metadata addresses.
Restrict RBAC permissions for creating or modifying ClusterPolicy and GlobalContextEntry resources to a minimal set of trusted operators.

Patch Information

Kyverno 1.19.1 addresses CVE-2026-100705 by extending the egress blocklist and scoped-token controls to the legacy apiCall service executor in pkg/engine/apicall/executor.go and to the GlobalContextEntry external-API path. Operators should upgrade using the official Helm chart or manifests and verify the running version with kubectl get pods -n kyverno -o jsonpath='{.items[*].spec.containers[*].image}'.

Workarounds

Apply a Kubernetes NetworkPolicy that denies egress from the Kyverno namespace to link-local metadata ranges and loopback.
Remove or disable any ClusterPolicy that templates the apiCall.service.url field from values contained in the admission resource.
Where upgrade is not immediately possible, migrate apiCall definitions to the CEL http.Get/http.Post library, which enforces the egress blocklist.

bash

# Example NetworkPolicy restricting Kyverno egress to metadata endpoints
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: kyverno-deny-metadata-egress
  namespace: kyverno
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32
              - 169.254.169.253/32
              - 127.0.0.0/8