Tag: multi-tenancy

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.