CVE-2026-84199

Kyverno before 1.16.2 contains a server-side request forgery (SSRF) vulnerability in the APICall feature. The URL field in a Policy's ServiceCall configuration is not validated, so a user with namespace-level Policy creation permissions can direct Kyverno to make HTTP requests to arbitrary internal resources (e.g., cloud metadata endpoints such as 169.254.169.254 or other tenants' resources). Because Kyverno executes these requests using its cluster-wide high-privilege ServiceAccount (a Confused Deputy problem), the responses—potentially including other tenants' secrets and cloud IAM credentials—are returned in the PolicyReport and can be read by the attacker, breaking multi-tenant isolation.

Kyverno before 1.16.2 contains a server-side request forgery (SSRF) vulnerability in the APICall feature. The URL field in a Policy's ServiceCall configuration is not validated, so a user with namespace-level Policy creation permissions can direct Kyverno to make HTTP requests to arbitrary internal resources (e.g., cloud metadata endpoints such as 169.254.169.254 or other tenants' resources). Because Kyverno executes these requests using its cluster-wide high-privilege ServiceAccount (a Confused Deputy problem), the responses—potentially including other tenants' secrets and cloud IAM credentials—are returned in the PolicyReport and can be read by the attacker, breaking multi-tenant isolation.

Summary

Kyverno's APICall feature contains a Server-Side Request Forgery (SSRF) vulnerability that allows users with Policy creation permissions to access arbitrary internal resources through Kyverno's high-privilege ServiceAccount. In multi-tenant Kubernetes environments, this constitutes a classic Confused Deputy problem: low-privilege tenants can steal sensitive data from other tenants (such as database passwords and API keys) and cloud platform IAM credentials, completely breaking tenant isolation. This vulnerability does not require cluster-admin privileges and can be exploited with only namespace-level Policy creation permissions.

Details

Vulnerability Mechanism

Kyverno's APICall feature allows Policies to fetch external data via HTTP requests. This feature does not validate target URLs when executing HTTP requests, leading to an SSRF vulnerability.

Source Point - User-Controlled URL

File: api/kyverno/v1/common_types.go, lines 247-250

type ServiceCall struct {
    // URL is the JSON web service URL
    URL string `json:"url"`  // User-controlled, no validation
    Headers []HTTPHeader `json:"headers,omitempty"`
    CABundle string `json:"caBundle,omitempty"`
}

The URL field is completely controlled by users through Policy configuration, with no validation mechanism to restrict target addresses.

Sink Point - HTTP Request Execution

File: pkg/engine/apicall/executor.go, lines 65-110

func (a *executor) executeServiceCall(ctx context.Context, apiCall *kyvernov1.APICall) ([]byte, error) {
    if apiCall.Service == nil {
        return nil, fmt.Errorf("missing service for APICall %s", [a.name](http://a.name/))
    }

    client, err := a.buildHTTPClient(apiCall.Service)
    if err != nil {
        return nil, err
    }

    req, err := a.buildHTTPRequest(ctx, apiCall)
    if err != nil {
        return nil, fmt.Errorf("failed to build HTTP request for APICall %s: %w", [a.name](http://a.name/), err)
    }

    // Line 80: Directly executes HTTP request without URL validation
    resp, err := client.Do(req)
    if err != nil {
        return nil, fmt.Errorf("failed to execute HTTP request for APICall %s: %w", [a.name](http://a.name/), err)
    }
    defer resp.Body.Close()

    // Read and return response content
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        // ...
    }

    return body, nil
}

Line 80's client.Do(req) directly executes the HTTP request without checking if the target URL is an internal IP address (like 169.254.169.254) or resources belonging to other tenants.

Confused Deputy Problem

In multi-tenant environments, Kyverno uses a cluster-wide high-privilege ServiceAccount to execute all APICall requests. When a low-privilege tenant creates a Policy containing malicious APICall directives, Kyverno executes these requests with its own high privileges, leading to privilege escalation.

Attack path:

Tenant A (namespace-level permissions)
  → Creates malicious Policy
  → Kyverno (cluster-wide high privileges)
  → Accesses Tenant B's Secrets / Cloud metadata service
  → Sensitive data leaked to PolicyReport
  → Tenant A reads PolicyReport to obtain data

PoC

Environment Setup

Prerequisites

• Kubernetes cluster
• Kyverno v1.16.0 installed
• Mock cloud metadata service (optional, for testing cloud credential theft)

Step 1: Install Kyverno

kubectl create namespace kyverno
kubectl create -f https://github.com/kyverno/kyverno/releases/download/v1.16.0/install.yaml
kubectl wait --for=condition=Ready pods --all -n kyverno --timeout=300s

Verify installation:

$ kubectl get pods -n kyverno
NAME                                             READY   STATUS    RESTARTS   AGE
kyverno-admission-controller-5c84845f5-28hz5     1/1     Running   0          2m
kyverno-background-controller-59b7b8d686-7pqxl   1/1     Running   0          2m
kyverno-cleanup-controller-5fd988d64f-nsgdb      1/1    …

Kyverno before 1.16.2 contains a server-side request forgery (SSRF) vulnerability in the APICall feature. The URL field in a Policy's ServiceCall configuration is not validated, so a user with namespace-level Policy creation permissions can direct Kyverno to make HTTP requests to arbitrary internal resources (e.g., cloud metadata endpoints such as 169.254.169.254 or other tenants' resources). Because Kyverno executes these requests using its cluster-wide high-privilege ServiceAccount (a Confused Deputy problem), the responses—potentially including other tenants' secrets and cloud IAM credentials—are returned in the PolicyReport and can be read by the attacker, breaking multi-tenant isolation.

Kyverno before 1.16.2 contains a server-side request forgery (SSRF) vulnerability in the APICall feature. The URL field in a Policy's ServiceCall configuration is not validated, so a user with namespace-level Policy creation permissions can direct Kyverno to make HTTP requests to arbitrary internal resources (e.g., cloud metadata endpoints such as 169.254.169.254 or other tenants' resources). Because Kyverno executes these requests using its cluster-wide high-privilege ServiceAccount (a Confused Deputy problem), the responses—potentially including other tenants' secrets and cloud IAM credentials—are returned in the PolicyReport and can be read by the attacker, breaking multi-tenant isolation.

Kyverno before 1.16.2 contains a server-side request forgery (SSRF) vulnerability in the APICall feature. The URL field in a Policy's ServiceCall configuration is not validated, so a user with namespace-level Policy creation permissions can direct Kyverno to make HTTP requests to arbitrary internal resources (e.g., cloud metadata endpoints such as 169.254.169.254 or other tenants' resources). Because Kyverno executes these requests using its cluster-wide high-privilege ServiceAccount (a Confused Deputy problem), the responses—potentially including other tenants' secrets and cloud IAM credentials—are returned in the PolicyReport and can be read by the attacker, breaking multi-tenant isolation.

Summary

Kyverno's APICall feature contains a Server-Side Request Forgery (SSRF) vulnerability that allows users with Policy creation permissions to access arbitrary internal resources through Kyverno's high-privilege ServiceAccount. In multi-tenant Kubernetes environments, this constitutes a classic Confused Deputy problem: low-privilege tenants can steal sensitive data from other tenants (such as database passwords and API keys) and cloud platform IAM credentials, completely breaking tenant isolation. This vulnerability does not require cluster-admin privileges and can be exploited with only namespace-level Policy creation permissions.

Details

Vulnerability Mechanism

Kyverno's APICall feature allows Policies to fetch external data via HTTP requests. This feature does not validate target URLs when executing HTTP requests, leading to an SSRF vulnerability.

Source Point - User-Controlled URL

File: api/kyverno/v1/common_types.go, lines 247-250

type ServiceCall struct {
    // URL is the JSON web service URL
    URL string `json:"url"`  // User-controlled, no validation
    Headers []HTTPHeader `json:"headers,omitempty"`
    CABundle string `json:"caBundle,omitempty"`
}

The URL field is completely controlled by users through Policy configuration, with no validation mechanism to restrict target addresses.

Sink Point - HTTP Request Execution

File: pkg/engine/apicall/executor.go, lines 65-110

func (a *executor) executeServiceCall(ctx context.Context, apiCall *kyvernov1.APICall) ([]byte, error) {
    if apiCall.Service == nil {
        return nil, fmt.Errorf("missing service for APICall %s", [a.name](http://a.name/))
    }

    client, err := a.buildHTTPClient(apiCall.Service)
    if err != nil {
        return nil, err
    }

    req, err := a.buildHTTPRequest(ctx, apiCall)
    if err != nil {
        return nil, fmt.Errorf("failed to build HTTP request for APICall %s: %w", [a.name](http://a.name/), err)
    }

    // Line 80: Directly executes HTTP request without URL validation
    resp, err := client.Do(req)
    if err != nil {
        return nil, fmt.Errorf("failed to execute HTTP request for APICall %s: %w", [a.name](http://a.name/), err)
    }
    defer resp.Body.Close()

    // Read and return response content
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        // ...
    }

    return body, nil
}

Line 80's client.Do(req) directly executes the HTTP request without checking if the target URL is an internal IP address (like 169.254.169.254) or resources belonging to other tenants.

Confused Deputy Problem

In multi-tenant environments, Kyverno uses a cluster-wide high-privilege ServiceAccount to execute all APICall requests. When a low-privilege tenant creates a Policy containing malicious APICall directives, Kyverno executes these requests with its own high privileges, leading to privilege escalation.

Attack path:

Tenant A (namespace-level permissions)
  → Creates malicious Policy
  → Kyverno (cluster-wide high privileges)
  → Accesses Tenant B's Secrets / Cloud metadata service
  → Sensitive data leaked to PolicyReport
  → Tenant A reads PolicyReport to obtain data

PoC

Environment Setup

Prerequisites

• Kubernetes cluster
• Kyverno v1.16.0 installed
• Mock cloud metadata service (optional, for testing cloud credential theft)

Step 1: Install Kyverno

kubectl create namespace kyverno
kubectl create -f https://github.com/kyverno/kyverno/releases/download/v1.16.0/install.yaml
kubectl wait --for=condition=Ready pods --all -n kyverno --timeout=300s

Verify installation:

$ kubectl get pods -n kyverno
NAME                                             READY   STATUS    RESTARTS   AGE
kyverno-admission-controller-5c84845f5-28hz5     1/1     Running   0          2m
kyverno-background-controller-59b7b8d686-7pqxl   1/1     Running   0          2m
kyverno-cleanup-controller-5fd988d64f-nsgdb      1/1    …

Kyverno before 1.16.2 contains a server-side request forgery (SSRF) vulnerability in the APICall feature. The URL field in a Policy's ServiceCall configuration is not validated, so a user with namespace-level Policy creation permissions can direct Kyverno to make HTTP requests to arbitrary internal resources (e.g., cloud metadata endpoints such as 169.254.169.254 or other tenants' resources). Because Kyverno executes these requests using its cluster-wide high-privilege ServiceAccount (a Confused Deputy problem), the responses—potentially including other tenants' secrets and cloud IAM credentials—are returned in the PolicyReport and can be read by the attacker, breaking multi-tenant isolation.

Kyverno APICall SSRF Vulnerability Leading to Multi-Tenant Isolation Breach in github.com/kyverno/kyverno