Kyverno 1.18: SSRF Patches, CEL Push, ClusterPolicy Out

Kyverno 1.18 shipped on May 5 as the project’s first release since graduating at the CNCF in March — and if you’re running ClusterPolicy on any cluster, this version starts a clock you can’t ignore. Two SSRF security patches landed, the CEL policy engine got new library support, and the deprecation countdown on ClusterPolicy continues toward its October 2026 removal in v1.20.

Upgrade First: Two SSRF Patches You Can’t Skip

Before anything else: 1.18 patches CVE-2026-4789 and CVE-2026-41323, both SSRF flaws in Kyverno’s HTTP-based policy execution.

CVE-2026-4789 was the nastier of the two. Namespace-scoped users could craft a policy that made arbitrary HTTP requests from the Kyverno admission controller pod itself — bypassing Kubernetes RBAC entirely. That opened a path to cloud provider metadata endpoints and internal cluster services. CVE-2026-41323 was a token-leakage issue in the apiCall feature: Kyverno included a scoped access token in outbound HTTP requests without restricting where those requests went.

The fix takes a clear stance. HTTP calls from policies are now restricted to cluster-scoped policies by default; namespaced policies need an explicit opt-in via configuration flags. Unsafe addresses — loopback, cloud metadata services — are on a default blocklist. Scoped tokens now only travel to validated destinations. If your Kyverno deployment uses the http CEL library or apiCall in any policy, upgrading to 1.18 is not optional.

What Else Is New in 1.18

Beyond the security hardening, the release adds a gzip CEL library for policy authors working with compressed resource data, improved compilation and evaluation of policy variables and conditions, and memory-based HPA autoscaling for admission controller deployments running at scale. TLS is now available on metrics endpoints, and a new successEventActions ConfigMap parameter gives teams fine-grained control over which success events get emitted — useful if your event volumes are drowning out the signals you actually care about.

The CLI gets meaningful updates too. kyverno apply and kyverno test now support cleanup policies, HTTP/Envoy authorization policies, and mutateExisting rules — meaning you can properly test the full range of your policy configurations locally before hitting the cluster.

The ClusterPolicy Clock Is Running

The real urgency in 1.18 isn’t the new features — it’s the deprecation timeline. Kyverno 1.17 formally deprecated ClusterPolicy and CleanupPolicy. They still work in 1.18, but v1.20 is scheduled for October 2026, and that’s when they come out.

The migration path splits ClusterPolicy’s bundled rules into discrete types: ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy, and DeletingPolicy. Each does one thing, uses CEL expressions instead of the old YAML pattern syntax, and maps directly to the direction Kubernetes upstream is taking admission controls.

The syntax change is real. Here’s the same “require memory limits” policy in both formats:

Before (ClusterPolicy):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-memory-limits
spec:
  rules:
    - name: check-memory
      match:
        resources:
          kinds: [Pod]
      validate:
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?"

After (ValidatingPolicy):

apiVersion: kyverno.io/v2beta1
kind: ValidatingPolicy
metadata:
  name: require-memory-limits
spec:
  matchResources:
    namespaceSelector: {}
  validations:
    - expression: >-
        object.spec.containers.all(c, has(c.resources) &&
        has(c.resources.limits) && 'memory' in c.resources.limits)
      message: "All containers must have memory limits."

The CEL version is more verbose and requires learning the expression language. That’s the honest tradeoff. Kyverno’s migration guide provides field-by-field mapping from legacy patterns to CEL equivalents, and kubectl explain vpol.spec is your reference for the new schema. There’s no automated migration tool — this is manual work, and October is closer than it looks.

Why CNCF Graduation Actually Matters

Kyverno’s graduation to CNCF’s highest maturity tier in March was more than a ribbon-cutting. Bloomberg, Coinbase, LinkedIn, Spotify, and the US Department of Defense’s Platform One all publicly rely on it. LinkedIn alone runs over 20,000 admission requests per minute through Kyverno across 230+ clusters. The graduation signals formal governance, a two-year roadmap commitment, and a support model organizations can build procurement around.

Starting with 1.18, Kyverno adopts a “main + 1” patch support model — roughly three months of patch support for critical and high-severity CVEs on the current and immediately preceding release. For teams on older versions, this is another nudge to stay current.

What to Do Now

Three steps:

1. Check your Kyverno version. If you’re on 1.16.x or earlier, upgrade to 1.18 for the CVE patches.
2. Audit your ClusterPolicy count. Run kubectl get clusterpolicy -A and start estimating the migration scope before October.
3. Read the full 1.18 release notes for the complete changelog including image verification reliability fixes for ImageValidatingPolicy.

Policy-as-code on Kubernetes is maturing fast. Kyverno’s CEL-first model aligns with upstream Kubernetes admission control direction, and the graduation backing means the project is here for the long term. October’s deadline is a forcing function — the migration work isn’t going to get easier by waiting.