CVE-2026-41068: Kyverno Privilege Escalation Vulnerability

CVE-2026-41068 Overview

CVE-2026-41068 is an Authorization Bypass vulnerability in Kyverno, a policy engine designed for cloud native platform engineering teams. The vulnerability exists in Kyverno's ConfigMap context loader, which fails to validate the configMap.namespace field. This allows a namespace administrator to read ConfigMaps from any namespace using Kyverno's privileged service account, resulting in a complete RBAC bypass in multi-tenant Kubernetes clusters.

This vulnerability is particularly concerning because it represents an incomplete fix for CVE-2026-22039, which addressed cross-namespace privilege escalation in Kyverno's apiCall context by validating the URLPath field. However, the ConfigMap context loader was overlooked and contains an identical vulnerability pattern.

Critical Impact

Namespace administrators can bypass Kubernetes RBAC controls to access sensitive ConfigMap data from any namespace in multi-tenant clusters, potentially exposing credentials, configuration secrets, and other sensitive information.

Affected Products

• Kyverno versions prior to 1.17.2

Discovery Timeline

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

Technical Details for CVE-2026-41068

Vulnerability Analysis

The vulnerability stems from CWE-863 (Incorrect Authorization), where the ConfigMap context loader in Kyverno accepts arbitrary namespace values without proper validation. When a Kyverno policy includes a ConfigMap context entry, the configMap.namespace field can be set to any namespace in the cluster. Kyverno's service account, which typically has elevated cluster-wide permissions to enforce policies, will then retrieve the ConfigMap from the specified namespace without verifying whether the policy author has legitimate access rights to that namespace.

This creates a privilege escalation vector in multi-tenant Kubernetes environments where namespace isolation is a critical security boundary. An attacker with namespace admin privileges in their own namespace can craft a Kyverno policy that references ConfigMaps in other namespaces (such as kube-system or namespaces belonging to other tenants), effectively using Kyverno as a proxy to bypass RBAC restrictions.

Root Cause

The root cause is missing authorization validation in the ConfigMap context loader (pkg/engine/context/loaders/configmap.go). The original implementation did not track or enforce the policy's namespace context when loading ConfigMaps, allowing cross-namespace access. The vulnerable configMapLoader struct lacked a policyNamespace field to restrict ConfigMap access to the policy's own namespace for namespaced policies.

Attack Vector

The attack vector is network-based and requires low privileges (namespace admin). An attacker exploits this by creating a Kyverno ClusterPolicy or namespaced Policy with a context entry that references a ConfigMap in a target namespace:

1. Attacker identifies a target ConfigMap containing sensitive data in another namespace
2. Attacker creates a Kyverno policy in their controlled namespace
3. The policy includes a ConfigMap context entry with namespace set to the target namespace
4. When the policy triggers, Kyverno's privileged service account retrieves the ConfigMap
5. The attacker can access the ConfigMap data through policy evaluation results or side effects

The patch adds namespace validation to ensure namespaced policies can only access ConfigMaps within their own namespace:

// Security patch in pkg/engine/context/loaders/configmap.go
// Source: https://github.com/kyverno/kyverno/commit/bbf3e5c01391d612968440659028ae98e565a777

 )
 
 type configMapLoader struct {
-	ctx       context.Context //nolint:containedctx
-	logger    logr.Logger
-	entry     kyvernov1.ContextEntry
-	resolver  engineapi.ConfigmapResolver
-	enginectx enginecontext.Interface
-	data      []byte
+	ctx             context.Context //nolint:containedctx
+	logger          logr.Logger
+	entry           kyvernov1.ContextEntry
+	resolver        engineapi.ConfigmapResolver
+	enginectx       enginecontext.Interface
+	data            []byte
+	policyNamespace string
 }
 
 func NewConfigMapLoader(

// Security patch in pkg/engine/factories/contextloaderfactory.go
// Source: https://github.com/kyverno/kyverno/commit/bbf3e5c01391d612968440659028ae98e565a777

 ) (enginecontext.DeferredLoader, error) {
 	if entry.ConfigMap != nil {
 		if l.cmResolver != nil {
-			ldr := loaders.NewConfigMapLoader(ctx, l.logger, entry, l.cmResolver, jsonContext)
+			ldr := loaders.NewConfigMapLoader(ctx, l.logger, entry, l.cmResolver, jsonContext, l.policyNamespace)
 			return enginecontext.NewDeferredLoader(entry.Name, ldr, l.logger)
 		} else {
 			l.logger.V(3).Info("disabled loading of ConfigMap context entry", "name", entry.Name)

Detection Methods for CVE-2026-41068

Indicators of Compromise

• Kyverno policies with ConfigMap context entries referencing namespaces other than their own
• Unexpected ConfigMap read operations from Kyverno's service account across namespace boundaries
• Audit logs showing Kyverno accessing ConfigMaps in sensitive namespaces like kube-system
• New or modified policies created by namespace admins that include cross-namespace ConfigMap references

Detection Strategies

• Enable Kubernetes audit logging and monitor for ConfigMap get or list operations by the Kyverno service account
• Review all existing Kyverno policies for ConfigMap context entries with explicit namespace fields
• Implement admission control policies to detect and alert on policies attempting cross-namespace ConfigMap access
• Deploy runtime security monitoring to detect anomalous ConfigMap access patterns

Monitoring Recommendations

• Configure alerts for any Kyverno policy creation or modification events
• Monitor Kubernetes audit logs for cross-namespace resource access by Kyverno service accounts
• Review RBAC bindings to identify namespace admins who could exploit this vulnerability
• Implement regular policy audits to identify potentially malicious ConfigMap context entries

How to Mitigate CVE-2026-41068

Immediate Actions Required

• Upgrade Kyverno to version 1.17.2 or later immediately
• Audit all existing Kyverno policies for ConfigMap context entries with cross-namespace references
• Review Kubernetes audit logs for signs of exploitation
• Consider temporarily restricting policy creation permissions until the patch is applied

Patch Information

The vulnerability is fixed in Kyverno version 1.17.2. The fix adds a policyNamespace field to the ConfigMap loader, ensuring that namespaced policies can only access ConfigMaps within their own namespace. The security patch is available in commit bbf3e5c01391d612968440659028ae98e565a777.

For detailed information, see the GitHub Security Advisory and the GitHub Commit.

Workarounds

• Restrict Kyverno policy creation to cluster administrators only using RBAC
• Implement an admission webhook to reject policies with cross-namespace ConfigMap references
• Remove ConfigMap read permissions from Kyverno's service account if ConfigMap context is not needed
• Use network policies to limit Kyverno's access to the Kubernetes API server

# Review existing policies for cross-namespace ConfigMap references
kubectl get clusterpolicies,policies -A -o json | jq '.items[] | select(.spec.rules[].context[]?.configMap.namespace != null) | {name: .metadata.name, namespace: .metadata.namespace}'

# Audit Kyverno service account permissions
kubectl auth can-i --list --as=system:serviceaccount:kyverno:kyverno-admission-controller -n kube-system | grep configmaps