CVE-2026-84195: Kyverno Information Disclosure Vulnerability

CVE-2026-84195 Overview

CVE-2026-84195 affects Kyverno versions before 1.16.4. The admission controller automatically attaches its ServiceAccount token to outbound HTTP requests when policies use apiCall service mode without explicit authorization headers. Attackers who control policy definitions or reachable endpoints can redirect these requests to attacker-controlled servers and capture the token. Possession of the token grants full control over Kyverno policies and cluster resources managed by the admission controller. The flaw is categorized as an information exposure issue [CWE-200].

Critical Impact
Exfiltration of the Kyverno admission controller's ServiceAccount token enables cluster-wide policy manipulation and lateral movement across Kubernetes workloads.

Affected Products

Kyverno versions prior to 1.16.4
Kubernetes clusters using Kyverno policies with apiCall service mode
Deployments where policies reference external or user-controllable URLs

Discovery Timeline

2026-09-01 - CVE-2026-84195 published to NVD
2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-84195

Vulnerability Analysis

Kyverno's apiCall context entry lets policies fetch data from HTTP endpoints during admission review. The controller runs with a ServiceAccount that has broad Kubernetes API permissions to evaluate and enforce policies. When apiCall fires, the client attaches the pod's mounted ServiceAccount token to the outbound request by default. This behavior applies even when the destination URL is external or outside the cluster's control plane. A malicious policy author, or an attacker who influences a URL used in apiCall, can direct the request to a server they control and log the Authorization header.

Once captured, the token authenticates against the Kubernetes API as the Kyverno controller. That access allows the attacker to modify or delete policies, disable enforcement, and interact with any resources the controller can read or write.

Root Cause

The root cause is missing scope control on credential attachment. The apiCall client does not distinguish between in-cluster Kubernetes API destinations and arbitrary external endpoints. It attaches the ServiceAccount bearer token unconditionally when no explicit authorization header is set on the request. This violates least-privilege handling of secrets and maps to [CWE-200] Exposure of Sensitive Information to an Unauthorized Actor.

Attack Vector

Exploitation requires the ability to define or influence a Kyverno policy containing an apiCall entry, or to control an endpoint referenced by an existing policy. The attacker sets the apiCall URL to a server they operate, waits for admission events to trigger the policy, and captures the bearer token from the incoming request. With the token, the attacker authenticates to the Kubernetes API and pivots. See the GitHub Security Advisory and the VulnCheck Advisory on Kyverno for full technical detail.

Detection Methods for CVE-2026-84195

Indicators of Compromise

Outbound HTTPS or HTTP requests from Kyverno admission controller pods to non-Kubernetes destinations
Authorization: Bearer headers observed in egress traffic originating from the kyverno namespace
Kyverno policies containing apiCall entries with external or unexpected URLs
Unusual Kubernetes API activity authenticated by the Kyverno ServiceAccount from external IPs

Detection Strategies

Audit all installed ClusterPolicy and Policy objects for context.apiCall.urlPath and apiCall.url fields referencing hosts outside the cluster API
Enable Kubernetes audit logging and alert on Kyverno ServiceAccount actions originating from unexpected source IPs
Inspect egress network flows from Kyverno pods and flag destinations that are not the in-cluster API server

Monitoring Recommendations

Deploy egress network policies restricting Kyverno pods to the Kubernetes API server and approved endpoints
Continuously monitor Kyverno pod outbound connections with a Cloud Workload Protection tool
Log and review admission webhook activity for policy changes that add or modify apiCall entries

How to Mitigate CVE-2026-84195

Immediate Actions Required

Upgrade Kyverno to version 1.16.4 or later in all clusters
Rotate the Kyverno controller ServiceAccount token and any credentials that may have been exposed
Review existing policies for apiCall entries pointing to external or untrusted URLs and remove or restrict them
Restrict who can create or modify Kyverno policies using Kubernetes RBAC

Patch Information

The fix is available in Kyverno 1.16.4. Refer to the GitHub Security Advisory for release notes and upgrade guidance.

Workarounds

Disable or remove policies that use apiCall service mode until upgrade is complete
Apply NetworkPolicy resources that block egress from the kyverno namespace to non-cluster destinations
Constrain policy authoring permissions to a small set of trusted administrators
Set explicit authorization headers on apiCall entries so the default ServiceAccount token is not attached

bash

# Example NetworkPolicy restricting Kyverno egress to the Kubernetes API only
# Adjust the API server CIDR to match your cluster
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: kyverno-egress-restrict
  namespace: kyverno
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.1/32
      ports:
        - protocol: TCP
          port: 443
EOF