リリース

Kyverno v1.18.1 is a targeted patch fixing two regressions in generate and mutate-existing policies introduced in v1.18.0.

• breakingUpgrade immediately if you use generate policies on cluster-scoped resources

  If you upgraded to v1.18.0 and have GeneratingPolicy rules targeting cluster-scoped resources (ClusterRoles, Namespaces, CRDs, etc.), generation was silently broken. v1.18.1 restores correct behavior. Validate that expected resources were actually generated after upgrading — anything that should have been generated during the v1.18.0 window may need manual remediation or a policy re-trigger.

• breakingMutate-existing policies on v1.18.0 may have produced incorrect results

  The AdmissionRequest context was not being forwarded to UpdateRequests in mutate-existing policies. This means any rule relying on request context (user info, object, oldObject) for conditional logic or patches would have behaved incorrectly. Audit mutations applied while running v1.18.0 and verify affected resources are in the expected state after upgrading to v1.18.1.

• enhancementTreat v1.18.0 as effectively broken for generate and mutate-existing users

  Both fixes were cherry-picked from main, meaning v1.18.0 should be skipped entirely if you rely on either feature. Skip straight to v1.18.1. If you are still on v1.17.x and evaluating the v1.18 line, start your testing against v1.18.1 instead.

v1.16.4 is a security-focused patch release addressing 15+ CVEs across Kyverno's dependency chain, plus a critical behavioral change that disables HTTP in namespaced policies by default.

• securityUpgrade immediately — 15+ CVEs patched, including supply chain components

  This release patches CVEs across sigstore/rekor, go-tuf, docker/cli, Go stdlib, and Kyverno's own code. Several of these touch the image verification and policy fetch paths. If you're running any image signing workflows with Kyverno, the rekor and go-tuf bumps are directly relevant. Plan an upgrade in your next maintenance window — do not wait for the next major cycle.

• breakingHTTP disabled by default in namespaced policies (CVE-2026-4789) — test before upgrading

  Namespaced policies that fetch external data over plain HTTP will silently stop working after this upgrade. If you use URL context sources or external data fetches in namespaced ClusterPolicy or Policy resources, audit them for HTTP (non-HTTPS) endpoints before upgrading. This is a security hardening change, but it will break existing policies that relied on insecure endpoints. Switch those endpoints to HTTPS or migrate to HTTPS-capable data sources first.

• breakingRestricted ConfigMap access for namespaced policies — RBAC may need review

  Namespaced policies now have reduced ConfigMap access scope. If your policies rely on reading ConfigMaps outside their namespace for context or configuration, those reads will fail post-upgrade. Review your policy definitions for cross-namespace ConfigMap references and adjust either the policy logic or the access grants accordingly before rolling out this version.

v1.17.2 is a security-heavy patch release addressing multiple CVEs and fixing critical bugs in MutatingPolicy, ValidatingPolicy, webhook reconciliation, and namespaced policy handling.

• securityUpgrade immediately — 6+ CVEs fixed in this release

  This release patches at least six CVEs across dependencies and Go stdlib, plus CVE-2026-4789 which disables HTTP in namespaced policies by default. If you run namespaced policies that rely on HTTP-based external data sources or webhooks, audit those configurations before upgrading — they will stop working silently. Upgrade path: update your Helm chart or manifests to v1.17.2 and validate policy behavior in a staging environment first.

• breakingNamespaced policies: HTTP disabled and ConfigMap access restricted

  Two separate hardening changes affect namespaced policies. HTTP is now disabled by default (CVE-2026-4789), and ConfigMap access has been scoped down. If your namespaced policies fetch context from HTTP endpoints or read ConfigMaps outside their namespace, those policies will fail silently or error post-upgrade. Run a dry-run or audit scan against your namespaced policies before deploying to production.

• enhancementWebhook reconciliation loop fix — reduces controller churn in large clusters

  Inconsistent webhook rule ordering was causing repeated reconciliation loops, which generates excess API server load and noisy controller logs. This is fixed. If you've been seeing constant webhook object churn in your audit logs or elevated kyverno-controller CPU, this release resolves it. No action needed post-upgrade, but worth monitoring controller metrics after rollout to confirm stabilization.

Kyverno v1.17.1 is a focused patch release fixing a CVE, multiple crash/panic conditions, race conditions, and image verification bugs that could silently misbehave in production.

• securityPatch CVE-2025-68121 now

  CVE-2025-68121 is fixed in this release. Details on scope are limited in the notes, but any CVE fix in an admission controller warrants immediate attention. If you're on v1.17.0, upgrade to v1.17.1 before doing anything else. Don't wait for your next maintenance window.

• breakingVerify your policy exclusion rules if you use empty lists

  A bug was fixed where an empty list in a policy exclusion would silently exclude ALL resources instead of none. If you have any ClusterPolicy or Policy with exclusion blocks, audit them now. If you were unknowingly relying on empty-list-as-exclude-all behavior (unlikely but possible), your policies will now behave correctly — meaning resources that were previously skipped will now be evaluated.

• enhancementImage verification with TSA and private registries is now reliable

  Two separate ivpol fixes land here: signed timestamp verification is now correctly enabled when a TSACertChain is provided, and private registry secrets in the Kyverno namespace are now used during background report scanning. If you've been seeing unexpected verification failures in background scans or with TSA-based signature policies, upgrade and re-run your report scans to get accurate results.