CVE-2026-40868: Kyverno Auth Bypass Vulnerability

CVE-2026-40868 Overview

CVE-2026-40868 is a confused deputy vulnerability in Kyverno, a policy engine designed for cloud native platform engineering teams. Prior to version 1.16.4, Kyverno's apiCall servicecall helper implicitly injects an Authorization: Bearer header using the Kyverno controller serviceaccount token when a policy does not explicitly set an Authorization header. Because context.apiCall.service.url is policy-controlled, this can send the Kyverno serviceaccount token to an attacker-controlled endpoint.

This vulnerability is classified under CWE-922 (Insecure Storage of Sensitive Information) and represents a significant security risk in Kubernetes environments where Kyverno is deployed for policy enforcement.

Critical Impact

An attacker who can create or modify ClusterPolicy resources can exfiltrate the Kyverno controller's serviceaccount token, potentially gaining elevated privileges within the Kubernetes cluster.

Affected Products

• Kyverno versions prior to 1.16.4
• ClusterPolicy configurations using context.apiCall.service calls
• Global context usage with external service calls

Discovery Timeline

• 2026-04-21 - CVE CVE-2026-40868 published to NVD
• 2026-04-22 - Last updated in NVD database

Technical Details for CVE-2026-40868

Vulnerability Analysis

The vulnerability exists in Kyverno's service call functionality used within policy contexts. When a ClusterPolicy or global context makes an external API call using context.apiCall.service, the Kyverno engine automatically attaches the controller's serviceaccount token as a Bearer authorization header if no explicit Authorization header is specified in the policy configuration.

This behavior creates a confused deputy scenario where the trusted Kyverno controller acts on behalf of a potentially malicious policy definition. An attacker with privileges to create ClusterPolicy resources can craft a policy that points to an attacker-controlled endpoint, causing Kyverno to inadvertently leak its highly privileged serviceaccount token.

Namespaced policies are protected from this attack because the namespaced urlPath gate in pkg/engine/apicall/apiCall.go blocks servicecall usage for namespace-scoped policies. However, ClusterPolicy and global context configurations remain vulnerable in versions prior to 1.16.4.

Root Cause

The root cause is the implicit injection of authentication credentials without explicit user consent or awareness. The apiCall servicecall helper assumes that all service calls should be authenticated with the controller's serviceaccount token, regardless of whether the destination endpoint is trusted or attacker-controlled.

This design decision violates the principle of least privilege and creates an insecure default behavior where sensitive credentials are transmitted to arbitrary endpoints specified in policy configurations.

Attack Vector

The attack requires network access and low privileges (ability to create or modify ClusterPolicy resources). An attacker can exploit this vulnerability by:

1. Creating a ClusterPolicy with a context.apiCall.service block that points to an attacker-controlled external endpoint
2. Triggering the policy evaluation through normal Kubernetes operations
3. Capturing the Kyverno serviceaccount token from the incoming request at the attacker's endpoint
4. Using the captured token to authenticate to the Kubernetes API with the privileges of the Kyverno controller

The vulnerability mechanism involves the implicit credential injection in the servicecall helper. When processing a ClusterPolicy with an external service call, Kyverno retrieves its serviceaccount token and automatically adds it as a Bearer token in the Authorization header. Since the destination URL is policy-controlled, an attacker can specify any endpoint, including malicious servers designed to capture credentials. For complete technical details, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-40868

Indicators of Compromise

• Unusual outbound network connections from Kyverno controller pods to external endpoints
• ClusterPolicy resources with context.apiCall.service.url pointing to non-trusted domains
• Authentication failures or unusual activity using Kyverno serviceaccount credentials
• Kubernetes API audit logs showing unexpected operations performed by the Kyverno serviceaccount

Detection Strategies

• Monitor ClusterPolicy resources for external service call configurations with suspicious or unknown URLs
• Implement network policies to restrict egress traffic from Kyverno controller pods to approved endpoints only
• Review Kubernetes audit logs for ClusterPolicy creation or modification events by non-administrative users
• Deploy runtime security monitoring to detect unusual token usage patterns from Kyverno serviceaccounts

Monitoring Recommendations

• Configure alerts for any ClusterPolicy changes that include context.apiCall.service configurations
• Implement egress traffic monitoring for Kyverno controller namespaces
• Enable Kubernetes audit logging at the RequestResponse level for policy-related resources
• Monitor for any external network connections from the Kyverno controller that deviate from expected baselines

How to Mitigate CVE-2026-40868

Immediate Actions Required

• Upgrade Kyverno to version 1.16.4 or later immediately
• Audit all existing ClusterPolicy resources for external service call configurations
• Implement network policies to restrict Kyverno controller egress to known trusted endpoints
• Review RBAC permissions to ensure only authorized users can create or modify ClusterPolicy resources

Patch Information

The vulnerability is fixed in Kyverno version 1.16.4. Organizations should upgrade to this version or later as the primary remediation action. The fix ensures that serviceaccount tokens are not implicitly attached to external service calls without explicit configuration, preventing the confused deputy attack scenario.

For detailed patch information, refer to the GitHub Security Advisory.

Workarounds

• Restrict ClusterPolicy creation and modification permissions to trusted administrators only using Kubernetes RBAC
• Implement network policies that prevent Kyverno controller pods from making connections to external endpoints
• Use admission controllers to validate and reject ClusterPolicy resources with external service call URLs
• Deploy service mesh policies to control and monitor egress traffic from the Kyverno namespace

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