High priorityDisclosed

Advisory · CVE-2026-124441

Kyverno generate rules can be tricked into writing policies into other namespaces

Kyverno before 1.19.2 contains an authorization bypass that lets namespaced tenants generate any resource kind in any namespace by templating a generate rule's kind and namespace with variables, causing the privileged background controller to write NetworkPolicies or RoleBindings into victim or kube-system namespaces, rated high at CVSS 8.8; fixed in 1.19.2.

Advisory published November 8, 2026Independent summary
Vendor
Kyverno
Product
Kyverno
Identifier / CWE
CVE-2026-124441
CWE-863
Action timing
Immediate
ELI5

Explain it like I’m five

Kyverno can copy rules into namespaces automatically. A flaw lets a tenant write a rule that says copy this into any namespace, and the background worker, which has powerful permissions, obediently writes network rules and role bindings into other tenants' namespaces or the system's own namespace.

SIMPLIFIED_ATTACK_PATH05 STEPS
  1. 01Tenant authors a Policy

    A namespaced tenant creates a Policy with a generate rule.

  2. 02Kind and namespace templated

    The rule's target kind and namespace are filled in with variables.

  3. 03Trigger fires

    A ConfigMap in the tenant's own namespace triggers the rule.

  4. 04Privileged write

    The background controller writes the generated resource into the victim namespace.

  5. 05Isolation broken

    NetworkPolicies or RoleBindings land in victim or kube-system namespaces.

What happened

Kyverno before 1.19.2 contains an authorization bypass vulnerability that allows namespaced tenants to generate any resource kind in any namespace by templating the generate rule’s kind and namespace with variables. Attackers can create a Policy and trigger a ConfigMap in their own namespace, causing the privileged background-controller to write NetworkPolicies or RoleBindings into victim or kube-system namespaces. The record rates it high at CVSS 8.8 under version 3.1, with network attack vector, low complexity, low privileges required, and no user interaction.

The write lands with the controller’s privileges, so a tenant can reshape network policy and access bindings outside their own namespace. The flaw is fixed in Kyverno 1.19.2.

What to do

  1. Inventory Kyverno deployments and record each version.
  2. Upgrade to Kyverno 1.19.2 or later.
  3. Audit generate rules for templated kind or namespace fields.
  4. Review NetworkPolicies and RoleBindings in kube-system and tenant namespaces for unexpected entries.
  5. Remove any generated resource that cannot be accounted for.
  6. Verify the deployed version after updating.

Management note

A policy engine that writes where a tenant points it is a namespace-escape bug with cluster-wide reach. Audit what was generated, not just what version is running.