Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVSS v4.0

  • 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.

  • A 9.8 CVE for hulumi describes the project’s own CI sandbox, not anything users install

    A 9.8 CVE for hulumi describes the project’s own CI sandbox, not anything users install

    CVE-2026-82857 carries a 9.8 CVSS v3.1 base score for an over-permissive IAM policy in the hulumi project’s own AWS sandbox account — a resource nobody who installs hulumi has, described with a version range that implies they do.

    What happened

    NVD published two CVE records for the open-source project kerberosmansour/hulumi on Monday, August 31, 2026, both at 9:17 a.m. UTC, both assigned by VulnCheck as CNA, and both scored 9.8 CRITICAL on CVSS v3.1 and 9.3 CRITICAL on CVSS v4.0.

    CVE-2026-82856 is a real defect in shipped code. NVD carries the description verbatim: “@hulumi/policies versions before 1.3.2 fail to properly validate set-qualified AWS IAM condition operators in GitHub OIDC trust policies. Attackers can use ForAnyValue:StringLike operators to hide wildcard GitHub Actions OIDC subject conditions from security guardrails.” The package is a policy inspector. Its job is to look at an AWS IAM trust policy and refuse the unsafe ones. Before 1.3.2 it matched only the bare StringLike and StringEquals condition operator keys, so a policy that wrote the same condition as ForAnyValue:StringLike sailed past the check — and a wildcard in a GitHub Actions OIDC sub claim is the condition that decides which repositories, branches, and forks may assume an AWS role. A guardrail that can be stepped around by spelling the operator differently is worth a CVE.

    CVE-2026-82857 is a different kind of thing. Its NVD description reads: “hulumi versions before v1.3.2 contain a privilege escalation vulnerability in the weekly integration IAM policy that allows role lifecycle operations on af-e2e-* roles without sufficient boundary restrictions. Attackers with the documented principal can create persistent higher-privilege roles in the sandbox account.”

    The weekly integration IAM policy. The sandbox account. The af-e2e-* role prefix. These are the project’s own continuous-integration plumbing. The maintainer’s advisory, GHSA-35qr-vx94-m5x3, describes the fix as removing unnecessary inline-policy and trust-update permissions and updating the documentation that recommended them. The affected resource is an IAM policy in an AWS account the project controls, and the qualifying condition is stated in the description itself: “Attackers with the documented principal.”

    Nothing about that reaches a downstream user. Installing hulumi 1.3.1 does not create the weekly integration policy in your account. It does not create af-e2e-* roles. It does not grant you, or anyone attacking you, the documented principal. The exposure described is the maintainer’s CI sandbox, and it was fixed there.

    The record does not say that. NVD lists vendor kerberosmansour, product hulumi, and a vulnerable range of versions 0 through 1.3.1, fixed in 1.3.2 — the standard shape of a record that means “upgrade or you are exposed.” The CVSS v3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. PR:N asserts that no privileges are required, in a record whose own description requires the attacker to hold a specific documented AWS principal. Those two statements cannot both be true.

    Two smaller record notes. CVE-2026-82856 was published on August 31, 2026 for a defect the maintainer disclosed publicly on May 15, 2026 in GHSA-q2f7-m237-v562, which GitHub reviewed on May 21, 2026 — the CVE arrives 108 days after public disclosure, and the GitHub advisory still shows “No known CVE.” And the two records give different CVSS v4.0 vectors for the same flaw: GitHub’s ends VC:H/VI:H/VA:N, VulnCheck’s ends VC:H/VI:H/VA:H. Both compute to 9.3, so the disagreement over whether availability is affected at all leaves no trace in the number anyone reads.

    On scale: @hulumi/policies recorded 4,739 downloads in the month ending August 29, 2026, per the npm registry’s own download API. This is a small package, and saying so is not a dismissal — it is the number that was missing.

    Why it matters

    This is the third batch of VulnCheck-assigned CVEs on small open-source projects that this site has had to check in three days, after the MCP server batch on August 30 and the MCPHub batch on August 31. The pattern across all three is the same, and it is worth naming plainly rather than repeating story by story: months-old maintainer advisories are being converted into CVE records in bulk, at CRITICAL scores, with version ranges and attack vectors that describe a more dangerous and more general situation than the underlying advisory does.

    Bulk CVE assignment is not a bad thing in itself. Plenty of real defects sit in GitHub advisories for months with no CVE, invisible to every scanner that keys on CVE IDs, and a CNA willing to do that unglamorous work is doing the ecosystem a favor. CVE-2026-82856 is a good example.

    The problem is what happens when the same pipeline meets something that is not a product defect. A CVE record is not a description; it is an instruction to machinery. Scanners read the version range and tell you that you are running vulnerable software. Dependency bots read it and open a pull request. Vendor-risk questionnaires read the score and ask you to attest that you have remediated all criticals. None of that machinery reads the description, and the description is the only place CVE-2026-82857 says the exposure is somebody else’s sandbox.

    So the cost is not that a maintainer’s CI hygiene got publicized. It is that everyone running hulumi will be told, by tools they trust, that they have a critical remotely exploitable vulnerability requiring no privileges — and when they read the advisory and find it does not apply to them, they learn that critical findings from this source can be safely ignored. That lesson generalizes. It will be applied next time to CVE-2026-82856, which does apply to them, and which is the one they should actually act on. Both records came out of the same batch at the same minute with the same score. Nothing in the metadata distinguishes the one that matters.

    PR:N is where this becomes concrete rather than philosophical. Privileges Required is not decoration; it is the field that separates “anyone on the internet” from “an insider with a specific credential,” and it is doing most of the work in the jump from a serious score to a 9.8. Setting it to None in a record whose description begins “Attackers with the documented principal” is not a judgment call about which reasonable people disagree. The description contradicts the vector, in the same record, in adjacent fields.

    There is a defensible way to publish an incident like this one. If a maintainer wants to disclose that their own CI account was over-permissioned, a repository advisory does that honestly, and hulumi’s does. What a CVE adds is a claim about affected installed versions, and where there are none, the honest range is empty. GHSA-35qr-vx94-m5x3 did not resolve in GitHub’s global Advisory Database when checked for this story; the repository is the correct home for a finding about a project’s own infrastructure.

    What to do

    If you use @hulumi/policies: upgrade to 1.3.2 or later. CVE-2026-82856 is real and the fix is in that release. Then audit the trust policies the old inspector approved: it is not enough to fix the inspector if it already waved through a policy containing a set-qualified wildcard. Grep your IAM trust policies for ForAnyValue: and ForAllValues: prefixes on StringLike and StringEquals, and check every GitHub OIDC sub condition for wildcards that widen the claim beyond the specific repository and ref you meant to trust.

    More generally, on GitHub OIDC to AWS: a trust policy that matches repo:org/name:* trusts every branch, tag, and pull request in that repository, including branches a fork contributor can create. Pin to the ref you mean — repo:org/name:ref:refs/heads/main — or to a named environment, and confirm the audience condition is present and exact.

    If CVE-2026-82857 appears in your scanner: it describes the hulumi project’s own AWS sandbox, not your installation. Upgrading to 1.3.2 will clear the finding because the version range says so, and there is no harm in upgrading. But do not treat it as evidence you were exposed, and do not let it set your expectations for the record next to it.

    If you run a CNA: the version range and the CVSS vector are the two fields that reach automation. When the description names a precondition — a specific principal, an internal account, a non-default deployment — the vector has to reflect it.

    Sourcing note

    Both CVE records were read from the NVD API at services.nvd.nist.gov/rest/json/cves/2.0, which supplied the descriptions quoted above, the CVSS v3.1 and v4.0 vectors and their scoring source ([email protected]), the CWE assignments (CWE-284 and CWE-269), the affected version ranges, and the publication timestamps of August 31, 2026 at 9:17 a.m. UTC. Neither record carried cisaExploitAdd, cisaActionDue, or cisaRequiredAction; neither vulnerability is in the KEV catalog and no federal deadline attaches to either.

    GHSA-q2f7-m237-v562 was read in the GitHub Advisory Database, which gives its publication date as May 15, 2026, its review date as May 21, 2026, a Critical severity, a CVSS v4.0 vector ending VA:N, and “No known CVE.” GHSA-35qr-vx94-m5x3 was read at its repository advisory URL; the corresponding global Advisory Database page returned 404 when checked. The download figure is from the npm registry download-counts API for the period ending August 29, 2026. Both CVSS v4.0 vectors were recomputed locally and both yield 9.3, which is stated above rather than inferred.

    Unresolved: whether VulnCheck intends CVE-2026-82857 to describe a downstream-reachable condition that the description does not convey, and whether the PR:N assignment was deliberate. VulnCheck was not contacted for this story, and its advisory pages were read as published. The maintainer was not contacted. No exploitation of either issue has been reported by anyone, and none is asserted here.

  • Eight MCPHub CVEs published in one second today, and the critical one was fixed in May

    Eight MCPHub CVEs published in one second today, and the critical one was fixed in May

    GitHub pushed eight CVE records for the Model Context Protocol hub into the National Vulnerability Database this afternoon, their fixes spread across six releases shipped between April 22 and August 23, and the path-traversal record among them is scored three different ways depending on where you read it.

    What happened

    Eight CVE records for MCPHub entered the National Vulnerability Database on Monday, August 31, 2026. The publication timestamps run from 6:17:19.610 p.m. UTC to 6:17:20.627 p.m. UTC — eight records in a little over one second. Every one carries [email protected] as its source identifier, and every one is still at NVD’s Received status, which means NVD has not analyzed any of them and every score on every record is GitHub’s.

    MCPHub is an open-source project by the developer samanhappy, published to npm as @samanhappy/mcphub. Its own description, repeated at the head of all eight CVE descriptions, is “a unified hub for centrally managing and dynamically orchestrating multiple MCP servers/APIs into separate endpoints with flexible routing strategies.” It is the piece of software an organization puts in front of a fleet of MCP servers so that its agents have one address to talk to.

    Here is the batch, with the fixed release named in each advisory and the date that release actually reached npm:

    CVE Flaw Score (source: GitHub) Fixed in Released to npm
    CVE-2026-79743 Path traversal via MCPB manifest name 6.9 medium (CVSS v4.0) 0.12.13 April 22, 2026
    CVE-2026-79748 Non-admin remote code execution via POST /api/servers 9.9 critical (CVSS v3.1) 0.12.15 May 2, 2026
    CVE-2026-79744 No authorization check on PUT /api/system-config 8.8 high (CVSS v3.1) 1.0.29 August 17, 2026
    CVE-2026-79750 Cross-tenant tool execution 7.7 high (CVSS v3.1) 1.0.30 August 20, 2026
    CVE-2026-79746 Bearer key scoped to one server grants a whole group 8.1 high (CVSS v3.1) 1.0.31 August 22, 2026
    CVE-2026-79745 No role check on prompt and resource writes 7.1 high (CVSS v3.1) 1.0.32 August 23, 2026
    CVE-2026-79747 Server-side request forgery, no egress filtering 7.1 high (CVSS v3.1) 1.0.32 August 23, 2026
    CVE-2026-79749 SSRF guard bypassed by IPv6 transition addresses 7.6 high (CVSS v4.0) 1.0.32 August 23, 2026

    The critical one is the oldest. GHSA-mx89-jjx9-gjr8, titled “Authenticated non-admin user achieves RCE via POST /api/servers (missing authorization on stdio command/args),” states plainly that “There is no authorization check restricting these endpoints to admins, and there is no allowlist/sanitization on the command and args fields.” The impact section says the result is “Remote code execution as the MCPHub process owner from a low-privilege authenticated account. In the official Docker image and in typical npx deployments, that user is root — full host compromise.” The reporter is credited as offset. The fix, version 0.12.15, went to npm on May 2, 2026, almost four months before the CVE record existed.

    The 8.8 record is close behind in reach if not in score. GHSA-4gc8-885f-qj36 says PUT /api/system-config is “protected only by the app-wide authentication middleware and a rate limiter,” so any authenticated non-admin can rewrite the settings that govern the whole instance. Setting skipAuth = true, the advisory notes, “converts the entire dashboard API into an unauthenticated admin surface,” and repointing values such as smartRouting.openaiApiBaseUrl or install.npmRegistry turns the hub into an exfiltration or supply-chain vector. GitHub’s summary calls it “a complete compromise of the instance and every tenant on it.” That advisory was published on August 17, 2026, credited to waydeshi.

    One record does not agree with itself across mirrors. CVE-2026-79743, the MCPB path traversal, is carried by NVD at 6.9 medium with the CVSS v4.0 vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X. GitHub’s own advisory page for GHSA-p3h2-2j4p-p83g gives 7.2 with a different v4.0 vector, AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H — privileges required low rather than none, and high integrity and availability impact rather than low and none. GitLab’s mirror of the same advisory publishes it as 8.1 high on CVSS v3.1. Same flaw, same assigning authority, three published severities, and the one that scanners consume from NVD is the only one that rates it medium. The two mirrors also disagree on the publication date: GitHub’s database gives April 19, 2026, GitLab’s gives April 22, 2026, which is the day the fixed release reached npm.

    The batch has no common scale. Six of the eight records carry a CVSS v3.1 vector and nothing else; two — CVE-2026-79743 and CVE-2026-79749 — carry a CVSS v4.0 vector and nothing else. Nothing on the records lets a reader rank the 7.6 against the 7.7, because they are not measured with the same instrument.

    The batch is also incomplete against its source. The repository’s advisory listing carries at least ten entries. Four — a template export that skips the ownership filter, an OAuth authorization server that does not enforce client authentication, cross-group tool execution via a missing group filter, and an open redirect in the OAuth denial flow — have no CVE at all. A keyword search of NVD for MCPHub returns twelve records in total: today’s eight plus four older ones from 2025 and April 2026. The cross-group tool execution advisory is rated high by GitHub and still has no CVE identifier.

    Why it matters

    An MCP hub is a credential concentrator by design. It holds every tenant’s server configuration, the OAuth client secrets, the JWT signing key, and the bearer keys, and it is wired to spawn processes and make outbound requests on behalf of whatever asks it to. That is the job. It means the interesting privilege boundary is not administrator versus anonymous, it is administrator versus ordinary authenticated user — and six of today’s eight records sit exactly on that line, requiring only low privileges.

    In a hub, “ordinary authenticated user” is frequently not a person. It is a service account, a CI job, or an agent holding its own bearer key. An agent that has been steered by a poisoned document or a hostile tool result is an authenticated low-privilege user with a shell, and CVE-2026-79748 turns that into code execution as root on the host in the project’s own container image. The defensive assumption that prompt injection is contained because the agent can only call approved tools does not survive a hub where calling an approved tool and registering a new one are the same permission.

    The timing is the second half of the problem, and it is the part that generalizes past this project. Severity Daily reported on Sunday that VulnCheck published thirteen MCP server CVEs in thirteen seconds. Today it is GitHub, eight records in about one second, for one project. The record for MCP infrastructure is arriving in bursts, months after the code was fixed, in batches large enough that no individual record gets read. An organization that patches on CVE feed learned today about a hole that was closed on May 2 — and if it is still on the 0.12 line, it learned about a hole it may still have.

    That inversion is worth naming. For most software the CVE is the early warning and the patch follows. Here the patch runs months ahead of the record, which makes the CVE feed a poor instrument for knowing whether your agent plumbing is current. Version currency is the better one, and few organizations yet apply it to the components their agents talk through.

    What to do

    Upgrade to 1.0.33, which reached npm on August 30, 2026 and is past every fixed version named in the eight advisories. There is no release that fixes only some of these; the fixes accumulated across 0.12.13, 0.12.15, 1.0.29, 1.0.30, 1.0.31, and 1.0.32.

    If you are pinned to the 0.12 line, know what that leaves you with: 0.12.15 closes the 9.9 and 0.12.13 closes the path traversal, but the 0.12 line carries none of the six August fixes, including the system-config authorization bypass and both SSRF issues.

    Independent of version, check three things. Confirm skipAuth is not set on your instance. Enumerate every non-admin account and bearer key that can reach the hub, including service and agent identities, and treat each as capable of everything described above on an unpatched build. And do not run the hub as root: the 9.9 advisory names the official Docker image and typical npx deployments as the case where the process owner is root, which is what converts a permissions bug into host compromise. Egress filtering in front of the hub limits both SSRF records; the IPv6 bypass in CVE-2026-79749 shows why the application’s own guard is not the place to rely on.

    Sourcing note

    Checked: NVD’s API records for CVE-2026-79743 through CVE-2026-79750, including publication timestamps, source identifiers, vulnerability status, and CVSS vectors; a keyword search of NVD for MCPHub, which returned twelve records; GitHub advisories GHSA-mx89-jjx9-gjr8, GHSA-4gc8-885f-qj36, and GHSA-p3h2-2j4p-p83g; the MCPHub repository’s advisory listing; GitLab’s advisory-database mirror of GHSA-p3h2-2j4p-p83g; and the npm registry metadata for @samanhappy/mcphub, which supplied the release dates for every version named above.

    Not resolved: NVD has not analyzed any of the eight records, so there is no independent score on any of them, and the medium rating on CVE-2026-79743 may change if NVD scores it. GitHub’s advisory page for GHSA-p3h2-2j4p-p83g did not show a CVE identifier at the time of checking even though NVD now maps CVE-2026-79743 to it. The two published dates for that advisory, April 19 and April 22, 2026, are reproduced as found rather than reconciled. No exploitation of any of the eight has been reported by GitHub, the maintainer, or any vendor, and none is claimed here. The four repository advisories without CVE identifiers are described from the repository’s own listing; whether identifiers are pending was not established.

  • ToolJet’s cross-tenant flaw is scored 9.9 and 2.4 on the same CVE record, by the same scorer

    ToolJet’s cross-tenant flaw is scored 9.9 and 2.4 on the same CVE record, by the same scorer

    Seven ToolJet authorization CVEs landed this morning. On the worst of them, the same scorer published a 9.9 and a 2.4 in the same record, and the vendor’s own advisory says 5.9.

    What happened

    At 9:17 a.m. UTC on August 31, 2026, seven ToolJet CVEs entered the National Vulnerability Database in a single batch. All seven were assigned by VulnCheck, whose batch publishing this publication examined yesterday. All seven describe the same class of defect in the same subsystem: the tooljet-db endpoints of ToolJet, a self-hosted low-code application builder, fail to check that an authenticated user actually belongs to the organization named in the request.

    The underlying engineering problem is described plainly in ToolJet’s own advisory, GHSA-w3hx-rg9g-mw5c, published August 7, 2026 and credited to a reporter named nekros1xx. The controller reads an organization ID out of the URL path and passes it into database operations without validating it. The authorization guard checks the user’s permissions against the tj-workspace-id header, which the user controls, and never cross-checks that header against the path parameter. The advisory states the consequence directly:

    “Any authenticated user with Builder privileges in any organization on the instance can read schema metadata, create tables, modify columns, and drop tables in arbitrary other organizations.”

    That advisory also documents how an attacker finds a victim organization’s UUID, and both routes work before authentication: public apps disclose organization IDs through /api/apps/slugs/:slug, and /api/login-configs/:organizationId/public functions as an oracle confirming whether a given organization exists. ToolJet rated the finding Moderate, at 5.9 on CVSS v3.1, and shipped the fix in v3.16.208.

    Three numbers, one flaw

    The CVE that corresponds to that advisory is CVE-2026-82874, published this morning. It carries two CVSS metrics, both from [email protected]:

    • CVSS v3.1, marked Primary: 9.9 CRITICAL — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
    • CVSS v4.0, marked Secondary: 2.4 LOW — CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:P/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L

    These are not two readings of the same evidence a point apart. They are 7.5 points apart, at opposite ends of the scale, and the vectors contradict each other on nearly every metric that matters. The v3.1 vector says the flaw is reachable across a network with no user interaction and produces high impact on confidentiality, integrity, and availability. The v4.0 vector says it is reachable only from an adjacent network, requires user interaction, and produces low impact on all three. Together with the vendor’s 5.9, one defect now carries a Low, a Moderate, and a Critical.

    The divergence is not confined to that record. Across the seven, comparing each record’s v3.1 score against its own v4.0 score:

    • CVE-2026-82869 — 7.7 v3.1 against 8.2 v4.0
    • CVE-2026-82870 — 9.6 against 7.0
    • CVE-2026-82871 — 7.7 against 8.2
    • CVE-2026-82872 — 9.1 against 7.1
    • CVE-2026-82873 — 5.0 against 5.3
    • CVE-2026-82874 — 9.9 against 2.4
    • CVE-2026-82875 — 5.5 against 5.1

    Three of the seven diverge by two points or more. More telling than the scores is a disagreement in the vectors that runs through the batch: on five of the seven records the v3.1 vector says AV:N and the v4.0 vector says AV:A. One says these are network-reachable flaws; the other says an attacker has to already be on an adjacent network segment. For HTTP endpoints on a web application, with a pre-authentication discovery path documented in the vendor’s own advisory, those two statements cannot both be describing the same deployment.

    One further inconsistency is worth recording because it changes what an administrator has to do. Six of the seven records give the fixed version as 3.16.208. CVE-2026-82869, covering the join_tables endpoint, gives it as 3.16.44. Both trace to real ToolJet advisories, so this is not obviously an error — but a reader scanning the batch for “the” fixed version will find two, and only one of them closes all seven.

    Why it matters

    CVSS v4.0 exists because v3.1 was known to be blunt — it modeled scope crudely, ignored attack requirements, and pushed too much of the software world into the 9-and-above band. The migration was supposed to produce better numbers. What it has produced, in records like this one, is two numbers and no rule for choosing between them.

    The rule that exists is a labeling convention, and it is doing real work here. NVD marks the v3.1 metric Primary and the v4.0 metric Secondary, so a tool that follows the labels reports 9.9 and pages someone. A tool configured to prefer the newest available CVSS version — a defensible setting, and one that vendors have encouraged as v4.0 adoption grows — reports 2.4 and files it for the next quarterly window. Two organizations running the same scanner with different, reasonable configurations get opposite instructions from one record. Neither is misreading the data. The data says both things.

    It is worth being precise about what is and is not in dispute. The defect is not in dispute: ToolJet found it, confirmed it, described the attack chain in detail, and fixed it three weeks ago. Nobody involved disagrees about what the code did. The entire disagreement is about the number attached to it afterward, which is to say about the layer that most organizations actually consume, because most organizations do not read advisories — they read a score in a queue that something else populated.

    There is also a question about the 9.9 itself that the vendor’s 5.9 puts squarely on the table. ToolJet, which knows its own product and wrote the advisory, put the flaw in the middle of the range. VulnCheck’s v3.1 vector reaches 9.9 partly through S:C, the scope-changed flag, which is reasonable for a cross-tenant defect. But the same scorer’s v4.0 vector then declined to treat the tenant boundary as significant at all, assigning low subsequent-system impact throughout. The two vectors encode incompatible judgments about whether crossing an organization boundary is a big deal, and both were published under the same identifier on the same morning.

    This is the second record failure this publication has documented today, and the fourth kind in a week. Earlier this morning we reported a Nodemailer CVE whose machine-readable range clears a version the vendor never claimed to have fixed. Before that: an advisory whose stated preconditions contradicted what its own researchers told reporters, a patched flaw whose fixing release was missing from the changelog, and a vendor scoring three of its own products at a flat 10.0. The engineering keeps being fine. The record describing it keeps not being.

    What to do

    Upgrade self-hosted ToolJet to v3.16.208 or later. That release closes the schema-operation defects, and it is well past 3.16.44, so it covers the join_tables issue in the same step. The fix has been available since August 7, 2026 — this batch of CVEs is paperwork catching up to a patch, not a new emergency.

    The exposure is specific to multi-tenant instances. If your ToolJet deployment hosts more than one organization — separate teams, separate customers, separate business units on one instance — every Builder-role user in any of them could reach every other one’s tables. A single-organization instance has no boundary to cross and is materially less exposed, though the join_tables and export defects still cross workspaces.

    If you cannot upgrade this week, audit who holds Builder role. The attack requires an authenticated account with that privilege somewhere on the instance; it is not exploitable by an anonymous visitor. Trimming Builder assignments to people who need them narrows the population that can reach the defect.

    For triage: do not let an automated pipeline consume a single scalar from these seven records without recording which CVSS version it took. If your ticket says 9.9 and your auditor’s report says 2.4, both were read off the same NVD entry, and reconciling them later will cost more than writing the version down now.

    Sourcing note

    All seven CVE records were read from the NVD API at services.nvd.nist.gov/rest/json/cves/2.0. The scores and vectors above are copied from those records; CVE-2026-82874 was fetched twice, individually, to confirm that the 2.4 CVSS v4.0 metric and its AV:A/UI:P vector are what the record actually contains and not an artifact of one read. The Primary and Secondary designations, the [email protected] source identifier on both metrics, the CWE assignments, and the versionEndExcluding values of 3.16.208 and 3.16.44 come from the same records.

    ToolJet’s advisory GHSA-w3hx-rg9g-mw5c was read directly in the ToolJet repository for the Moderate rating, the 5.9 CVSS v3.1 score, the August 7, 2026 publication date, the credit to nekros1xx, the quoted description of the impact, the two pre-authentication organization-ID discovery routes, and the fixed version. The quoted sentence is reproduced exactly as the advisory writes it.

    Unresolved. We have not established why the two vectors on CVE-2026-82874 diverge, and we are not asserting that either is deliberate — a transposed or mis-entered v4.0 vector would produce this result as readily as a considered second opinion. VulnCheck has published no correction as of this writing and we have not contacted it. We were not able to enumerate ToolJet’s full advisory index for August 2026 through automated fetching, so we cannot say whether all seven CVEs have corresponding vendor advisories or what ToolJet rated the other six; only GHSA-w3hx-rg9g-mw5c and the existence of GHSA-7vj5-wxfm-gmfq were confirmed. No exploitation of any of these flaws has been reported, none is in CISA’s Known Exploited Vulnerabilities catalog, and no federal deadline attaches to them.