Kyverno 1.19.1 Namespace Clamp Bypass Reaches Cluster Admin

A fix that checks one string and acts on another is not much of a fix, and that is the short version of a critical advisory against Kyverno. According to the GitHub security advisory GHSA-39w8-hv5g-f73w, published October 23, 2026, the namespace restriction added in Kyverno 1.19.1 can be bypassed, and a tenant who can only create policies in their own namespace can escalate to full cluster admin.

What to do

The advisory lists Kyverno 1.19.1 as affected and 1.19.2 as the patched release. It also says the problem is present on the project’s main branch at the time of reporting. Upgrade to 1.19.2 or later. Until then, review who holds permission to create namespaced Policy objects, since that single privilege is the entry point the advisory describes.

What the advisory says

Kyverno policies can make Kubernetes API calls through an apiCall context. For namespaced policies, a clamp introduced in 1.19.1 is supposed to keep those calls inside the policy’s own namespace. The advisory describes the clamp as validating a decoded and cleaned copy of the request path while the request itself goes out against the raw path. When the decoding step fails, the check falls back to the raw string, and the API server, which always decodes fully, can then route the call somewhere the clamp never examined.

Because the call runs as the Kyverno admission controller’s service account, the advisory says the tenant can read other namespaces and create cluster-scoped admission webhooks they are not entitled to, which leads to cluster admin. The advisory also says this reopens the issues tracked as GHSA-c5qq-7g2q-cpqp and GHSA-5qq8-67g6-4h2w, which the 1.19.1 release was meant to close. We are deliberately leaving out the input details here; the advisory is the place for them.

Analysis

This is a recurring shape in multi-tenant tooling: a guard is added after a report, and it validates a normalized representation of the input while the downstream system consumes the original. The advisory itself notes that a narrow patch against one specific input would close none of the broader class, which suggests the durable fix is to check and send the same value. That is our reading, not a claim from the maintainers.

The practical stake is the trust model. A policy engine runs with broad privileges so that tenants do not have to, and any path that lets a tenant borrow those privileges turns a namespace boundary into a suggestion.

For background on how cluster-level trust boundaries have failed elsewhere recently, see our coverage of the Tailscale SSH disclosure and the Wasmtime sandbox escapes. More in the cloud hub.