TL;DR:
A subtle bug in Kyverno (before v1.13.5 & v1.14.) let users with Kubernetes API access bypass essential security policies. That flaw has since been patched. This post dives into how it happened, shows a code snippet, breaks down exploitation, and points to deeper reading.

What is Kyverno?

Kyverno is a policy engine for Kubernetes. Devs and security teams use it to automatically enforce security, resource, and best practice rules across clusters. Kyverno policies can enforce what workloads can run, mutate config, or validate incoming specs — all without writing custom webhooks.

The Vulnerability

Versions of Kyverno before 1.13.5 or 1.14. failed to properly handle an error in a key function:
GetNamespaceSelectorsFromNamespaceLister in pkg/utils/engine/labels.go.

Kyverno policies can use *namespace selectors* to match which namespaces a policy rule applies to.

- Under certain conditions (for example, if Kyverno could not fetch namespace labels), an internal error happened.

Result? Critical security checks never happened.

So if you wrote a policy to *only* mutate or validate workloads in certain namespaces — and Kyverno quietly hit an error fetching those selectors — your policy just never ran. An attacker with *Kubernetes API access* (often by design for app teams) could sneak in workloads that sidestep restriction, deploy malicious pods, or escalate permissions, all without those policies ever stopping them.

Code Snippet: The Core Flaw

Here’s roughly what tripped up Kyverno, inspired by the actual function:

// What they had (simplified)
func GetNamespaceSelectorsFromNamespaceLister(ns string) []labels.Selector {
    selectors, err := someNamespaceLister.GetSelectors(ns)
    if err != nil {
        // silently move on! No error returned or logged
        return nil
    }
    return selectors
}

// The policy engine checks selectors, finds nothing, so doesn't do matching

The Fix:
The patched version now properly returns (and logs) the error so admissions can *fail* instead of silently ignoring policies.

1. Attacker identifies a Kyverno cluster using affected versions.

### 2. The attacker, with API access, creates or mutates a resource in a namespace relying on a Kyverno policy that uses namespace selectors.
### 3. If Kyverno encounters a namespace lister error, it *does not enforce* the policy — the attacker's resource is admitted unchecked.

Escalate permissions if policies blocking certain roles or secrets are skipped.

Real World Impact:
Even with strict Kyverno policies in place, a *cluster might be wide open* if Kyverno silently fails to match policies due to a simple error.

Upgrade Kyverno IMMEDIATELY:

- Go to v1.13.5+ or v1.14.+.

Original References

- CVE-2025-46342 on GitHub advisory *(replace with actual link when public)*
- Kyverno release notes - 1.13.5
- Patch diff PR *(replace with actual PR link)*

Final Thoughts

This is one of those *classic tiny bug, huge consequence* stories. If you're using Kyverno, don't assume silence is safe:
"If your policy engine can't check, you have no policy at all."
Patch up, audit, and double-check those logs.


Need help understanding your policy coverage or auditing for bypasses? I'm happy to advise further — drop me a message.

*Stay secure, and don't let admissions slip through the cracks!*


*(This writeup is exclusive — you won’t find this breakdown anywhere else. Please share responsibly.)*

Timeline

Published on: 04/30/2025 15:16:02 UTC
Last modified on: 05/16/2025 16:42:35 UTC