Kyverno 1.18, the First Release Since CNCF Graduation, Hardens HTTP Policy Calls and Starts the Countdown on ClusterPolicy
Kyverno 1.18 patches two flaws in its HTTP-based policy execution, blocks loopback and metadata addresses by default, and flags ClusterPolicy for deprecation later this year.
Overview
Kyverno, the policy-as-code engine for Kubernetes, has shipped version 1.18 — its first release since the project graduated within the Cloud Native Computing Foundation. According to the CNCF, the update is described as “our first release since graduating within the Cloud Native Computing Foundation,” and it leans heavily on security: it patches two vulnerabilities in Kyverno’s HTTP-based policy execution and changes the defaults around how policies are allowed to reach out across the network.
The release is tagged v1.18.0 on the project’s GitHub repository.
What We Know
Two patched flaws and tighter HTTP defaults
The headline change is a tightening of the feature that lets Kyverno policies make outbound HTTP calls. The release notes published by the CNCF reference two identifiers, CVE-2026-4789 and CVE-2026-41323, tied to that functionality.
Kyverno 1.18 ships safer defaults to address the risk. Per the CNCF, “by default, unsafe addresses like loopback and metadata services are blocked,” with operators able to configure an allow list and a block list for both cluster-scoped and namespaced policies. The project’s GitHub release corroborates the mechanism, listing a change to “enforce blocklist and add FLAG_HTTP_BLOCKLIST override.”
The new defaults also draw a line between cluster-scoped and namespaced policies. According to the CNCF, “HTTP calls from namespaced policies are default disabled, and need to be explicitly enabled using configuration flags.” The release additionally narrows what a leaked credential can do: the CNCF notes that “HTTP calls include a separate scoped token that ensures that servers cannot misuse the token.”
ClusterPolicy enters deprecation
Kyverno 1.18 also begins winding down ClusterPolicy, the bundled resource type that has historically carried Kyverno’s validation, mutation, and generation rules. The CNCF states that “ClusterPolicy resources are planned for deprecation later this year,” and points users toward a set of newer, discrete policy types: ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy, and DeletingPolicy.
CEL additions and a defined support window
For policy authors, the release adds tooling around Common Expression Language (CEL). The CNCF cites the addition of a “gzip CEL library for more advanced expressions.” On the command line, the GitHub release notes expanded kyverno apply and kyverno test support, including cleanup policies, HTTP and Envoy authorization policies, and mutateExisting rules.
The project is also formalizing how long releases get fixes. The CNCF says “Kyverno will follow a ‘main + 1’ patch support model,” under which “the current release (main) and the immediately previous release will be supported for patches,” amounting to roughly three months of community patch support for critical and high-severity CVEs.
Background
Kyverno reached the CNCF’s Graduated maturity level earlier this year. The foundation announced the milestone on March 24, 2026, noting that the project joined the CNCF in 2020 and had grown from 574 to more than 9,000 GitHub stars, with production adopters including Bloomberg, Coinbase, Deutsche Telekom, Groww, LinkedIn, Spotify, Vodafone, and Wayfair, according to the CNCF.
In that announcement, Chris Aniszczyk, CTO of CNCF, said “Kyverno’s graduation highlights how important policy-as-code has become for organizations running cloud native in production at scale,” per the CNCF. Jim Bugwadia, Kyverno co-creator and CEO of Nirmata, said “As AI adoption accelerates, policy-as-code provides the essential guardrails for autonomous governance at scale,” the CNCF reported.
What We Don’t Know
The CNCF release notes describe ClusterPolicy as “planned for deprecation later this year” but do not, in that posting, fix a specific removal version or calendar date for the migration. The precise timeline for retiring the resource type — and the practical migration burden for clusters with large existing ClusterPolicy inventories — is not detailed in the release announcement.