Act nowDisclosed

Advisory · CVE-2026-122302

Kyverno generate rules let namespace admins create resources cluster-wide

Kyverno before 1.19.2 checks generate-rule admission against the controller's permissions instead of the author's, so a namespace admin can make the background controller create or clone resources in other namespaces or at cluster scope. Kyverno rates it CVSS 3.1 9.8.

Advisory published November 5, 2026Independent summary
Vendor
Kyverno
Product
Kyverno
Identifier / CWE
CVE-2026-122302
CWE-269
Action timing
Immediate
ELI5

Explain it like I’m five

Kyverno checks whether its own powerful helper is allowed to do something, instead of checking whether the person asking is allowed. A namespace admin can ask the helper to build things outside their own namespace.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Policy with generate rules

    A namespace admin creates a namespaced Policy with generate rules targeting other namespaces or cluster-scoped kinds.

  2. 02Admission check looks at the wrong identity

    The generate-rule admission check verifies the controller's permissions, not the author's.

  3. 03Background controller acts

    The privileged background controller creates or clones the requested resources cluster-wide.

  4. 04Namespace boundary gone

    Resources appear outside the author's namespace, beyond what their RBAC allows.

What happened

Kyverno disclosed CVE-2026-122302 for Kyverno before 1.19.2. The generate-rule admission check verifies the controller’s permissions rather than the author’s, so a namespace admin can create a namespaced Policy with generate rules targeting other namespaces or cluster-scoped kinds. The background controller then creates or clones those resources cluster-wide.

The advisory rates it critical at CVSS 3.1 9.8 and identifies Kyverno 1.19.2 as the fixed release.

What to do

  1. Inventory Kyverno installations and confirm the deployed version.
  2. Upgrade affected installations to Kyverno 1.19.2 or later using the project release guidance.
  3. While remediation is underway, limit who can create namespaced Policies with generate rules.
  4. Review Kubernetes audit logs for generate-rule policies created by namespace admins and for resources created outside their home namespace.
  5. Check whether unexpected cluster-scoped or cross-namespace resources appeared and remove anything unauthorized.

Management note

This is a privilege escalation in the admission path itself: the control that is supposed to enforce namespace boundaries was checking the wrong identity. Treat it as a cluster-wide trust boundary failure, not a single-namespace issue.