The Kubernetes policy engine’s own GitHub advisories, most of them published in April, still say “No known CVE” — including the one a third-party CNA rated 9.0 critical today.
What happened
On Tuesday, September 1, 2026, VulnCheck published 22 CVE records. Six of them are for Kyverno, the CNCF admission controller that enforces policy on Kubernetes clusters. NVD received them between 12:17:11 p.m. and 12:17:49 p.m. UTC — a span of 38 seconds.
The six, in the order NVD received them, with the fixed version each names:
- CVE-2023-54356 — 3DES cipher suites on Kyverno’s TLS endpoints, exposing it to Sweet32. Fixed in 1.9.5 and 1.10.0.
- CVE-2025-15613 — server-side request forgery through the Service Call feature, which “also resolves external addresses” despite being documented for in-cluster services. Fixed in v1.13.4.
- CVE-2026-84195 — Kyverno “automatically attaches the admission controller’s ServiceAccount token to outbound HTTP requests in apiCall service mode without explicit authorization headers.” Fixed in 1.16.4.
- CVE-2026-84196 — SSRF in
apiCall.service.urlvia variable substitution, with “response data reflected in admission error messages enabling non-blind data exfiltration.” Fixed in 1.18.0. - CVE-2026-84199 — SSRF in the APICall feature reaching “cloud metadata endpoints such as 169.254.169.254 or other tenants’ resources,” which VulnCheck’s record names explicitly as “a Confused Deputy problem.” Fixed in 1.16.2.
- CVE-2026-84200 — the policy bypass: with two PolicyExceptions in play, “the less restrictive exception takes precedence,” letting an attacker defeat an enforce-mode policy by naming a resource to match the second exception’s pattern. Fixed in v1.13.0.
Every one of these cites a Kyverno GitHub Security Advisory as its first reference. Those advisories are not new. GHSA-gg4x-fgg2-h9w9, the source for the critical policy bypass, was published on January 6, 2026 and credits the researcher r0binak. The advisories behind the apiCall and SSRF records were published on April 13 and April 15, 2026. The fix for the policy bypass, v1.13.0, shipped on October 29, 2024.
Checked at 4:35 p.m. UTC today, four hours after the CVE appeared, the GitHub Advisory Database entry for GHSA-gg4x-fgg2-h9w9 still displays a CVE ID of “No known CVE.”
The scores do not agree with each other
CVE-2023-54356 carries two scores from the same source, VulnCheck, on the same record. Its CVSS v3.1 base score is 3.7, low, on the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N — network reachable, high attack complexity, low confidentiality impact and nothing else. Its CVSS v4.0 base score is 9.3, critical, on CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N — low complexity, and high confidentiality, integrity, and availability impact.
The record’s own description does not support the v4.0 reading. It says the 64-bit block ciphers are “vulnerable to the Sweet32 attack (CVE-2016-2183), which, over very long-lived TLS connections carrying large volumes of traffic, could allow an attacker to recover small amounts of plaintext.” Recovering small amounts of plaintext is not high integrity impact and it is not high availability impact. A 5.6-point spread between two scoring systems applied by one scorer to one paragraph is not a version difference. It is an error in one of them.
There is a second, quieter inconsistency. CVE-2026-84199 and CVE-2025-15613 carry byte-identical CVSS v4.0 vectors — CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L, both scoring 6.9 — while their v3.1 scores differ (7.7 versus 6.5) and their descriptions differ materially. One describes a confused-deputy read of other tenants’ secrets and cloud IAM credentials. The other describes exfiltration of policy context data. They are not the same finding, and both v4.0 vectors say the confidentiality impact is none.
A third conflict is in the version data. CVE-2026-84200’s description and the underlying GHSA both scope the flaw to v1.9.0 through v1.12.7. NVD’s machine-readable configuration for the same record marks everything from 0 up to 1.13.0 as vulnerable. A scanner reading the prose and a scanner reading the CPE range will disagree about releases before 1.9.0.
Why it matters
Kyverno is not an application that happens to be on a cluster. It is the thing that says no. It is where organizations put “no hostPath volumes,” “no privileged containers,” “images must come from this registry and carry this signature.” When an admission controller is bypassed, it does not alert. The pod is admitted, the deployment succeeds, and the audit record shows a compliant cluster. CVE-2026-84200 is the bypass case, and the example in the advisory is precisely the one that matters: a policy blocking hostPath volumes, defeated by naming a pod to match a second exception’s wildcard.
Three of the six records concern the same underlying design fact, which is worth stating plainly because it is the reason these scores understate the situation. Kyverno’s apiCall feature lets a policy fetch data over HTTP to make a decision. Kyverno performs those requests using its own cluster-wide, high-privilege ServiceAccount, and — per CVE-2026-84195 — attached that token to outbound requests automatically. SSRF in an ordinary web application gets an attacker a request from inside the network. SSRF in a control-plane component that carries a cluster-scoped credential gets them a request from inside the network with the cluster’s most privileged token in the header. VulnCheck’s own text for CVE-2026-84195 says the outcome is “full control over Kyverno policies and cluster resources.” That is a description of cluster takeover attached to a 7.7.
The record problem is the larger story, and it has now appeared three times in four days. Severity Daily has reported thirteen MCP server CVEs published by VulnCheck in thirteen seconds, and a 9.8 VulnCheck record describing a project’s own CI sandbox rather than anything users install. The shape repeats: a third-party CNA reconstructs a CVE record for a defect the project already disclosed in its own advisory, months later, in a batch, and the project’s advisory is not updated to point back.
None of that is misconduct. Assigning identifiers to real, already-public defects is a service, and the alternative — flaws that never get an ID at all — is worse for everyone running a scanner. But the timing has an operational consequence that is easy to miss. Between April and this morning, an organization running vulnerability management keyed on CVE identifiers had nothing to key on for the Kyverno apiCall and SSRF issues. The advisories existed on GitHub. The fixes existed in the release stream. The identifier that most enterprise tooling actually consumes did not. Today it does, for all of them at once, which means a great many dashboards are about to light up simultaneously for defects that were fixed months ago — in the case of the critical policy bypass, nearly two years ago.
The scoring conflict compounds it. This publication reported last week that ToolJet’s cross-tenant flaw was scored 9.9 and 2.4 on the same CVE record by the same scorer. Kyverno’s Sweet32 record is the same failure in the opposite direction: the older, better-understood scoring system says this barely matters, and the newer one says it is critical. An operator triaging by severity will either patch a 3DES cipher configuration ahead of a cluster-takeover SSRF, or ignore both. Neither is the right answer, and the record does not help them find it.
What to do
Upgrade Kyverno. The highest fixed version named across these six records is 1.18.0; running 1.18.0 or later closes all of them, and there is no partial upgrade path that does. If you cannot move immediately, 1.16.4 closes four of the six.
Independent of version, treat the ability to create Policies, ClusterPolicies, and PolicyExceptions as a privileged grant, because on the affected versions it is one. Audit who holds it. Several of these records require nothing more than namespace-level policy creation permission.
Restrict egress from the Kyverno admission controller’s pods. A network policy that permits only in-cluster destinations removes the exfiltration path for the apiCall and Service Call issues even where the code fix is not yet deployed, and blocking 169.254.169.254 specifically removes the cloud metadata route.
Inventory your policies for apiCall and service blocks. Most clusters use few or none. Those that use them, and pass variable-substituted user input into a URL, are the ones with real exposure rather than theoretical exposure.
Finally, if you triage by CVSS, do not triage these by CVSS. Read the six descriptions. They take five minutes and they are more accurate than any of the twelve numbers attached to them.
Sourcing note
All six CVE records, scores, vectors, version ranges, and publication timestamps were read from the NVD API, which is NIST republishing the CNA’s submission. VulnCheck’s own advisory pages were checked for CVE-2026-84200. The Kyverno project’s GitHub Security Advisory listing and the GitHub Advisory Database entry for GHSA-gg4x-fgg2-h9w9 were read directly; the “No known CVE” status was confirmed at 4:35 p.m. UTC on September 1, 2026, and may change. The v1.13.0 release date was taken from the Kyverno release page and the project’s release announcement.
Not established: whether VulnCheck coordinated these assignments with the Kyverno maintainers, why the six were published together today rather than when the underlying advisories appeared, whether the CVE-2023-54356 v4.0 vector is a data-entry error or a deliberate rating, and whether the Kyverno project intends to update its advisories with the new identifiers. No exploitation of any of these is reported, none appears in CISA’s Known Exploited Vulnerabilities catalog, and no federal remediation deadline attaches to any of them. The Kyverno project has not commented publicly on the batch as of this writing. Requests to cisa.gov are refused to automated clients, so KEV status here is inferred from the absence of CISA fields in the NVD records rather than from the catalog itself.