CVE-2026-41323: Kyverno Information Disclosure Flaw

CVE-2026-41323 Overview

CVE-2026-41323 is a critical information disclosure vulnerability in Kyverno, a policy engine designed for cloud native platform engineering teams. The vulnerability exists in Kyverno's apiCall feature within ClusterPolicy, which automatically attaches the admission controller's ServiceAccount token to outgoing HTTP requests without proper validation of the destination URL. This flaw allows the service URL to point anywhere, including attacker-controlled servers, enabling token theft that can lead to full Kubernetes cluster compromise.

Critical Impact
The stolen ServiceAccount token has permissions to patch webhook configurations, allowing attackers to gain complete control over the Kubernetes cluster through privilege escalation and unauthorized access to cluster resources.

Affected Products

Kyverno versions prior to 1.18.0-rc1
Kyverno versions prior to 1.17.2-rc1
Kyverno versions prior to 1.16.4

Discovery Timeline

April 24, 2026 - CVE-2026-41323 published to NVD
April 27, 2026 - Last updated in NVD database

Technical Details for CVE-2026-41323

Vulnerability Analysis

This vulnerability (CWE-200: Exposure of Sensitive Information to an Unauthorized Actor) affects Kyverno's admission controller component. When a ClusterPolicy uses the apiCall feature to make external HTTP requests, the admission controller automatically includes its ServiceAccount token in the request headers for authentication purposes. However, the implementation fails to validate or restrict the destination URLs, creating a critical security gap.

The admission controller's ServiceAccount typically possesses elevated privileges within the Kubernetes cluster, including the ability to modify webhook configurations. When an attacker can specify or influence the target URL in an apiCall directive, they can redirect these authenticated requests to a server they control, capturing the ServiceAccount token in the process.

Root Cause

The root cause lies in the lack of URL validation in the apiCall feature combined with automatic token attachment. The pkg/engine/apicall/executor.go component processes outbound HTTP requests without verifying that the destination is a trusted endpoint. This design assumed all configured URLs would be legitimate internal services, failing to account for scenarios where attackers could manipulate policy configurations or where misconfigured policies might expose tokens.

Attack Vector

An attacker with the ability to create or modify ClusterPolicy resources can configure an apiCall rule pointing to an external server under their control. When the policy is evaluated during admission control, Kyverno makes an HTTP request to the attacker's server with the ServiceAccount token included. The attacker captures this token and uses it to authenticate to the Kubernetes API server, leveraging the admission controller's permissions to escalate privileges and compromise the cluster.

The attack can be executed remotely and requires high privileges (ability to create/modify ClusterPolicy resources), but once successful, it leads to complete cluster takeover due to the scope change nature of the vulnerability.

// Security patch introducing scoped token handling
// Source: https://github.com/kyverno/kyverno/commit/bc4f91c4801b1eaa2edc0a14e2f1b0af8cf0c1f5

 	)
 	// parse flags
 	internal.ParseFlags(appConfig)
+	apicall.SetScopedTokenClientTimeout(apiCallTimeout)
 	var wg wait.Group
 	func() {
 		// setup

The patch introduces scoped token handling via apicall.SetScopedTokenClientTimeout() to restrict token usage and adds URL validation through string-based checks in the executor component.

Detection Methods for CVE-2026-41323

Indicators of Compromise

Unusual outbound HTTP requests from the Kyverno admission controller pods to external or unexpected destinations
ServiceAccount token usage from non-cluster IP addresses in Kubernetes API server audit logs
Unauthorized modifications to webhook configurations or other privileged cluster resources
ClusterPolicy resources containing apiCall rules pointing to non-internal service URLs

Detection Strategies

Enable Kubernetes API server audit logging and monitor for ServiceAccount token authentication from unexpected source IPs
Implement network policies to restrict egress traffic from Kyverno admission controller pods to approved destinations only
Deploy runtime security monitoring to detect anomalous API calls from the Kyverno namespace
Use admission controller policy scanning to identify ClusterPolicy resources with potentially malicious apiCall configurations

Monitoring Recommendations

Configure alerts for any webhook configuration changes, particularly those affecting the Kyverno admission webhook
Monitor Kyverno pod network connections for requests to external IP addresses or unexpected domains
Track ServiceAccount token usage patterns and alert on deviations from established baselines

How to Mitigate CVE-2026-41323

Immediate Actions Required

Upgrade Kyverno to version 1.18.0-rc1, 1.17.2-rc1, or 1.16.4 or later immediately
Audit all existing ClusterPolicy and Policy resources for apiCall rules and verify destination URLs are legitimate
Rotate the Kyverno admission controller ServiceAccount token after patching
Review Kubernetes API server audit logs for any signs of token misuse or unauthorized access

Patch Information

Kyverno has released patched versions addressing this vulnerability. The fix implements scoped token handling and URL validation to prevent unauthorized token exposure. Security patches are available via the following commits:

Kyverno Commit Update - Primary fix for version 1.18.x
Kyverno Commit Change - Backport for version 1.17.x
Kyverno Commit Revision - Backport for version 1.16.x

For complete details, see the GitHub Security Advisory.

Workarounds

Implement strict NetworkPolicy resources to block egress traffic from Kyverno pods to external networks
Remove or disable any ClusterPolicy resources using the apiCall feature until patching is complete
Use OPA Gatekeeper or manual review processes to prevent creation of policies with external apiCall URLs

bash

# Example NetworkPolicy to restrict Kyverno egress traffic
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: kyverno-restrict-egress
  namespace: kyverno
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: kyverno
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector: {}
  - to:
    - ipBlock:
        cidr: 10.0.0.0/8
EOF