CVE-2026-22039: Kyverno Auth Bypass Vulnerability

CVE-2026-22039 Overview

CVE-2026-22039 is a critical authorization boundary bypass vulnerability in Kyverno, a policy engine designed for cloud native platform engineering teams. This vulnerability affects versions prior to 1.16.3 and 1.15.3, allowing authenticated users with permission to create namespaced Policies to exploit Kyverno's admission controller ServiceAccount to perform unauthorized Kubernetes API requests across namespace boundaries.

Critical Impact

This vulnerability enables cross-namespace reads of sensitive resources (ConfigMaps, Secrets) and allows cluster-scoped or cross-namespace writes (including creating ClusterPolicies) by manipulating the urlPath through context variable substitution.

Affected Products

• Kyverno versions prior to 1.16.3
• Kyverno versions prior to 1.15.3
• Kubernetes environments running vulnerable Kyverno deployments

Discovery Timeline

• 2026-01-27 - CVE CVE-2026-22039 published to NVD
• 2026-01-29 - Last updated in NVD database

Technical Details for CVE-2026-22039

Vulnerability Analysis

This authorization bypass vulnerability (CWE-269: Improper Privilege Management) exists in the namespaced Kyverno Policy apiCall functionality. The core issue stems from the resolved urlPath being executed using the Kyverno admission controller's ServiceAccount credentials without enforcing that requests remain scoped to the policy's namespace.

When a namespaced Policy executes an apiCall, Kyverno processes the request using its admission controller identity, which typically has elevated RBAC permissions across the cluster. The vulnerability allows an attacker to manipulate the urlPath through context variable substitution, effectively hijacking Kyverno's privileged service account to access resources outside the intended namespace scope.

This breaks fundamental Kubernetes namespace isolation principles, enabling:

• Cross-namespace read access to ConfigMaps and potentially Secrets
• Cluster-scoped resource manipulation
• Creation of ClusterPolicies from namespaced policy contexts
• Horizontal privilege escalation across namespace boundaries

Root Cause

The root cause is the lack of authorization boundary enforcement on the urlPath parameter within namespaced Policy apiCall operations. The Kyverno admission controller does not validate that the resolved API path targets resources within the policy's own namespace, allowing authenticated users to craft policies that access arbitrary API endpoints permitted by Kyverno's ServiceAccount RBAC configuration.

Attack Vector

The attack is network-based and requires low privileges—specifically, any authenticated user with permission to create namespaced Policies can exploit this vulnerability. The attacker crafts a malicious Policy definition with a carefully constructed urlPath using context variable substitution to target resources outside the policy's namespace. When Kyverno processes this policy, it executes the API call using its admission controller ServiceAccount, which typically has broad cluster access.

For example, an attacker in namespace "user-ns" could create a Policy with an apiCall that reads Secrets from "kube-system" or creates ClusterPolicies—operations that should be restricted to cluster administrators.

Detection Methods for CVE-2026-22039

Indicators of Compromise

• Unexpected apiCall patterns in Kyverno Policy definitions targeting cross-namespace resources
• Anomalous Kubernetes API audit logs showing Kyverno ServiceAccount accessing resources outside expected namespaces
• Creation of ClusterPolicies or cluster-scoped resources initiated from namespaced Policy contexts
• Unusual read operations against Secrets or ConfigMaps in privileged namespaces (e.g., kube-system, kyverno)

Detection Strategies

• Enable Kubernetes audit logging and monitor for Kyverno ServiceAccount API calls that cross namespace boundaries
• Implement admission webhooks or OPA policies to validate urlPath patterns in Kyverno Policy definitions before creation
• Review existing namespaced Policies for suspicious apiCall configurations with variable substitution in urlPath
• Monitor for newly created ClusterPolicies and correlate with namespaced Policy activity

Monitoring Recommendations

• Configure alerts for Kyverno admission controller ServiceAccount activities outside designated namespaces
• Implement runtime monitoring for Policy resource creation events with apiCall rules
• Review RBAC permissions assigned to Kyverno's ServiceAccount and consider applying principle of least privilege
• Enable SentinelOne Kubernetes monitoring for anomalous workload behavior and API access patterns

How to Mitigate CVE-2026-22039

Immediate Actions Required

• Upgrade Kyverno to version 1.16.3 or 1.15.3 immediately to patch the vulnerability
• Audit existing namespaced Policies for potentially malicious apiCall configurations
• Review Kubernetes audit logs for evidence of exploitation attempts
• Restrict Policy creation permissions to trusted administrators only until patches are applied

Patch Information

The Kyverno maintainers have released patched versions 1.16.3 and 1.15.3 that address this vulnerability. The fix implements proper authorization boundary enforcement for apiCall operations within namespaced Policies.

Relevant commits:

• GitHub Commit e0ba4de
• GitHub Commit eba60fa

For additional details, refer to the GitHub Security Advisory GHSA-8p9x-46gm-qfx2.

Workarounds

• Temporarily restrict RBAC permissions for creating namespaced Policy resources to cluster administrators only
• Limit Kyverno's admission controller ServiceAccount RBAC to reduce the scope of potential exploitation
• Implement admission control to block Policies containing apiCall rules until patches are applied
• Consider network policies to restrict Kyverno's API server communication if immediate patching is not feasible

# Verify Kyverno version after upgrade
kubectl get deployment -n kyverno kyverno-admission-controller -o jsonpath='{.spec.template.spec.containers[0].image}'

# Audit existing policies for apiCall usage
kubectl get policy --all-namespaces -o json | jq '.items[] | select(.spec.rules[].context[].apiCall != null) | {namespace: .metadata.namespace, name: .metadata.name}'