Severity Daily

IT and AI security incidents, checked against the primary source

Tag: ToolJet

  • Four of today’s nine stories are about the gap between a fix and the record of it

    Four of today’s nine stories are about the gap between a fix and the record of it

    The item to act on tonight is Ruby on Rails, and it is not the biggest-sounding thing that happened today. Rails’ patch for CVE-2026-66066 stops the file read that leaks secret_key_base. It does not stop the Marshal deserialization gadget that read exposed, which still executes on a fully patched server for anyone holding a valid key. An organization that upgraded in early August and did nothing else is closed to the theft and still open to code execution by whoever completed the theft first. Patch status and compromise status have come apart here, and the step that reconciles them — rotating secret_key_base and every other secret readable from the application process — is the one no scanner reports as missing. VulnCheck says exploitation began the week of August 24. That claim is thin, and it is not what should decide this: a working exploit against more than 7,100 exposed instances has been public since August 7.

    Bigger headlines were available today, and both of them shrank on inspection. The Justice Department rewrote its China hacking announcement so that NASA, the Federal Reserve, and the Senate are now “among the targets” of QTFY rather than its victims — a withdrawal, not an escalation. And a 9.8 critical CVE for the open-source project hulumi turns out to describe an over-permissive IAM policy in the project’s own CI sandbox account, a resource nobody who installs hulumi has.

    The day did have a thread, and it is a narrow one: in four of the nine stories, the fix and the record of the fix do not match. Rails is one. Nodemailer’s new 9.8 names 8.0.3 as the fixed version, and the 8.0.3 tarball on npm still carries the vulnerable line. Eight MCPHub CVEs published within a single second this afternoon carry fixes shipped between April 22 and August 23 — the critical remote code execution among them was fixed in May and disclosed today. And Eclipse Theia’s agent-mode workspace escape, an 8.8 that let the AI agent write and delete files outside the workspace on a model-supplied path, was closed in a release whose notes described the change only as a breaking API change. The engineering is not the failure in any of the four. The patch exists in all of them. What is unreliable is the thing a vulnerability management program actually reads.

    Second for most shops is Microsoft’s confirmation that Windows is falsely reporting Defender as turned off across effectively every supported client and server version, with no originating update to roll back, no named build to compare against, and alerts that persist even when notification settings are off. Expect it at the service desk at boot tomorrow, and brief staff with Get-MpComputerStatus rather than “ignore it” — the alert being trained out is the tamper signal.

    Then the rest. Seven ToolJet CVEs describe the same cross-tenant authorization gap in tooljet-db, and the worst of them carries a 9.9 and a 2.4 from the same scorer in the same record, against the vendor’s own 5.9. Nutex Health refiled its August 24 breach disclosure under Item 1.05 seven days later without adding the materiality determination that item exists for — a change of flag that automated screening will read and the filing’s own text contradicts.

    Still open: Microsoft has named neither the Defender build that causes the false alert nor a fix date. VulnCheck has published no correction on the ToolJet scoring conflict or the Nodemailer fixed-version range. The Justice Department has not said which, if any, of the seven named bodies QTFY actually compromised, and the pre-edit wording survives only in contemporaneous reporting. Nutex has not said whether it made a materiality determination, and the affected-individual count will come from state and federal breach portals, not EDGAR. And the Rails exploitation claim still rests on one social media post that VulnCheck’s own weekly report for that week does not list.

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