al-ice.ai

Kyverno (CVE-2026-22039) — Namespaced Policy apiCall can cross namespace boundaries

• Category: AI CVEs

  • What happened: a critical authorization boundary bypass was disclosed for Kyverno’s Policy apiCall external data source, tracked as CVE-2026-22039.
  • Core issue: the resolved urlPath for apiCall is executed using Kyverno’s admission controller ServiceAccount, but it is not constrained to the Policy’s namespace.
  • Who can trigger it: any authenticated user who can create a namespaced Kyverno Policy (not cluster-wide) can potentially abuse this, depending on RBAC and Kyverno configuration.
  • What it enables: cross-namespace reads (e.g., ConfigMaps and potentially Secrets) and even cluster-scoped or cross-namespace writes if Kyverno’s ServiceAccount RBAC allows the targeted API paths.
  • Why it’s subtle: this isn’t “user gets more RBAC” directly — it’s user-controlled requests performed by a privileged controller identity, which tends to slip through reviews.
  • Fix signal: the advisory links directly to upstream commits addressing the behavior.

Why it matters

  • Kyverno sits on the security boundary: admission controllers are meant to enforce policy, so a namespace isolation bypass can have disproportionate blast radius.
  • Policy engines are “meta-privileged”: the controller often has broad Kubernetes API access to do its job; any path where untrusted users can influence controller API calls is high-risk.
  • Agentic automation loves policies: teams increasingly use policy-as-code and AI-assisted policy generation. If policies can trigger privileged API calls, you need stronger review gates, not just “YAML linting.”

What to do

  1. Patch/upgrade Kyverno to a version containing the fix for CVE-2026-22039 (verify against the upstream advisory and the referenced commits).
  2. Audit RBAC for Kyverno’s admission controller ServiceAccount: ensure it has the minimum set of verbs/resources; avoid broad * permissions.
  3. Validate exposure (defensive): in a non-prod cluster you own, try creating a namespaced Policy that uses apiCall to read a benign object outside the namespace (e.g., a known ConfigMap) and confirm the request is denied after patching.
  4. Constrain who can create Kyverno Policies: treat Policy/ClusterPolicy creation like code deployment — require PR review and CI policy tests.

Sources