Severity Daily

IT and AI security incidents, checked against the primary source

Tag: Kyverno

  • F5 njs access control fails open on an exception; nginx-saml parses attacker XML before checking the signature

    F5 njs access control fails open on an exception; nginx-saml parses attacker XML before checking the signature

    F5 published seven CVE records on September 2, and the sharpest is an access-control module that lets the request through when its own code throws an exception.

    What happened

    Seven vulnerability records naming F5 as the assigning authority reached the National Vulnerability Database on Wednesday, September 2, 2026, timestamped 4:17 p.m. UTC. Six of them are new. The seventh, CVE-2026-63020, a 3.1-rated spoofed-error-message issue in the BIG-IP configuration utility, points back to an older knowledge-base article and appears to be a backfill rather than part of this release.

    Three of the six are in NGINX JavaScript, the scripting module usually written as njs, and all three are fixed in njs 1.0.1.

    The one worth reading first is CVE-2026-18329, scored 8.2 under CVSS v3.1 and 8.8 under CVSS v4.0 by F5’s own product security team, with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N — network reachable, no privileges, no user interaction. The record describes a js_access handler doing asynchronous request-body processing, where “an exception is thrown during asynchronous access-control evaluation before an explicit access denial is returned.” The consequence is stated plainly: the access phase can fail open. The njs 1.0.1 changelog is blunter, calling it an “Access control bypass in js_access.” Affected njs versions are 0.9.9 and 1.0.0.

    CVE-2026-78689 is a heap out-of-bounds write in njs’s XML module, reachable through xml.exclusiveC14n() when it parses a crafted namespace prefix list. What makes it more than a parser bug is where F5 says that parser sits: the record singles out the nginx-saml reference implementation, which processes untrusted InclusiveNamespaces/@PrefixList values before it validates the signature. Affected njs versions run from 0.7.10 up to 1.0.1.

    CVE-2026-78222, 7.5 and 8.7, crashes an NGINX worker. F5’s text: “A vulnerability exists in NGINX JavaScript where a malformed HTTP response received by ngx.fetch() can crash an NGINX worker when trusted JavaScript reads Response.statusText.” The njs changelog names the specific trigger — an upstream “status line with an empty reason phrase.” It is classified CWE-476, a null pointer dereference, and it reaches back to njs 0.5.1, the widest affected range in the batch.

    Two more are configuration-generator injection flaws, both CWE-76. CVE-2026-77180, 8.3 and 8.7, is in NGINX Ingress Controller: “Multiple user-controllable fields are written into the generated NGINX configuration without sanitization.” An attacker who can write Ingress annotations through the Kubernetes API can inject directives, touch files, or take the service down. Affected: 5.0.0 through 5.6.0, and the long-term-support line 2026-lts-r1 through 2026-lts-r5. F5 credits kodareef5. CVE-2026-66362, 8.1 and 8.6, is the same shape in NGINX Gateway Fabric running NGINX Plus as its data plane, where values “from the Authentication Filter Custom Resource Definition clientID or cookieName fields, or in the clientSecret field of a Secret referenced by an Authentication Filter, are rendered directly into NGINX configuration templates without sanitization or escaping.” Fixed in 2.6.8.

    The sixth is not NGINX at all. CVE-2026-66842, 8.8 and 8.7, is a BIG-IP privilege escalation: “BIG-IP has a vulnerability where an authenticated user of any role may be able to create administrative user accounts” through an undisclosed request to the Traffic Management User Interface. F5 lists no workaround. It is credited to Dan Stefan Alexandru of Pentest-Tools and also affects BIG-IQ’s TMOS module.

    F5 reports no exploitation for any of the seven, and none carries a CISA KEV entry.

    Why it matters

    A fail-open access control is a different category of defect from a bug in software that happens to be exposed. js_access exists for one purpose: to decide whether a request is allowed. When the thing that decides has a failure mode of “allow,” every deployment that leaned on it has been quietly weaker than its configuration said, and nothing in a log would necessarily show it. The attacker’s job is not to find a bypass but to make the handler throw, and the exception does not have to come from the security logic itself.

    The remediation guidance is worth reading closely for the same reason. Alongside the upgrade, F5’s workaround for CVE-2026-18329 tells operators to “wrap your logic in a robust try/catch block with a default strict deny policy that returns an HTML 403 Forbidden response code.” It is also an instruction to write the deny-by-default behavior yourself, in a module whose entire job was to provide it. Anyone who deployed js_access without thinking through what happens on an unhandled rejection was relying on a guarantee the module did not make.

    CVE-2026-78689 carries a second lesson about ordering. Parsing attacker-controlled XML before checking the signature that is supposed to establish trust is a recurring failure across SAML implementations, and it turns a memory-safety bug in a namespace parser into a pre-authentication one. The reference implementation being the named at-risk consumer matters, because reference implementations get copied.

    That CVE also shows something about how severity is being reported right now. F5 scored it 8.1 High under CVSS v3.1 with AC:H, and 9.2 Critical under CVSS v4.0 with AC:L/AT:P. Same flaw, same assigner, same record, two different bands. This is not carelessness — v4.0 moved the “there is a precondition” idea out of attack complexity into a separate Attack Requirements metric, so the condition that pushed the v3.1 score down is represented differently rather than dropped. But a team that filters on “Critical” sees this flaw and a team that filters on the v3.1 base score does not, and both are reading the same record. F5’s v3.1 vector also asserts C:H/I:H/A:H, full compromise, while the record’s own text puts code execution at possible and unconfirmed: the score grades the worst case, the prose does not.

    The two injection flaws land in a familiar place: the boundary between “can edit Kubernetes objects” and “can execute in the proxy.” Ingress annotations and custom-resource fields feel like configuration, not code, and they are handed to people well short of cluster administrator. Where a template renders those strings unescaped, the RBAC grant that looked like a routing permission is a proxy-configuration permission.

    There is an awkward wrinkle in the recommended compensating control. F5 suggests admission policy — naming Kyverno, OPA Gatekeeper, and ValidatingAdmissionPolicy — to reject resources containing special characters. That is the right instinct. It is also worth knowing that Kyverno had a policy-exception bypass record, CVE-2026-84200, published to NVD the day before this batch, which this site covered on September 1. Admission policy is still worth deploying. But a compensating control is only as good as its own patch level, and an organization reading only F5’s advisory would not learn that.

    What to do

    • njs: upgrade to 1.0.1. This closes CVE-2026-18329, CVE-2026-78689, and CVE-2026-78222. The ranges differ — 0.9.9 and 1.0.0 for the access bypass, 0.7.10 up for the XML write, 0.5.1 up for the worker crash — so an old njs is exposed to the last two even if it predates the first.
    • If you run js_access: do not wait on the upgrade to add the try/catch and explicit 403 deny default F5 describes. Audit any handler doing asynchronous body work for paths that can throw.
    • If you run nginx-saml or anything derived from it: treat this as pre-authentication reachable and prioritize accordingly.
    • NGINX Ingress Controller: upgrade to 5.6.0, or 2026-lts-r5 on the LTS line. Until then, tighten RBAC so that write access to Ingress annotations is limited to trusted administrators, and add an admission policy that rejects special characters in annotation values.
    • NGINX Gateway Fabric: upgrade to 2.6.8. Review who can create or edit Authentication Filter resources and the Secrets they reference.
    • BIG-IP: upgrade to 21.1.0.1, 21.0.0.3, 17.5.1.8, or 17.1.3.4 depending on branch; BIG-IQ to 8.4.2.1. There is no workaround, so management-interface exposure is the only lever until you patch. TMUI should not be reachable from user networks, and this record is the argument for checking rather than assuming.
    • If you use ngx.fetch(): F5’s guidance is to “restrict ngx.fetch() destinations to trusted servers and avoid reading Response.statusText for responses from attacker-controlled or attacker-influenced endpoints.”

    Sourcing note

    Every CVE identifier, score, vector, affected range, and quoted description here comes from the CVE Program record API at cveawg.mitre.org and from NVD, both read on September 2, 2026. F5’s product security team is the assigning authority for all seven, so the descriptions and both CVSS vectors are F5’s own language and F5’s own grading, republished — there is no independent NVD analysis on these records yet, and no CWE assigned by anyone but F5.

    F5’s own knowledge-base articles — K000162599, K000162600, K000162601, K000162602, K000162603, and K000162521 — could not be read. my.f5.com returns a page whose body is a loading state; the advisory text is assembled in the browser and is not available to a non-browser fetch. That is the same pattern this site documented in HPE’s support portal on September 1. The version and remediation detail above is therefore recovered from the CVE records rather than read from the vendor page, and anything F5 said only in those articles is not reflected here.

    The njs 1.0.1 changelog was read from the project’s GitHub releases and corroborates all three njs entries, including the empty-reason-phrase trigger for CVE-2026-78222. That listing returned inconsistent release years to automated fetching, so no date is taken from it; the September 2, 2026 publication dates come from the CVE records.

    Unresolved: whether F5 grouped these into a quarterly security notification, and under what number, is not determinable from the records. No KEV entry exists for any of the seven, checked against NVD’s CISA fields, which lag the catalog by hours. No exploitation is claimed by F5 or observed in public reporting as of publication.

  • Kyverno got six CVEs in 38 seconds from a third-party CNA, and the lowest-risk one is scored 3.7 and 9.3 on the same record

    Kyverno got six CVEs in 38 seconds from a third-party CNA, and the lowest-risk one is scored 3.7 and 9.3 on the same record

    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.url via 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.