CVE-2026-73068

CVE-2026-73068 in ToolJet exposes a cross-tenant authorization failure where the caller's workspace (from the tj-workspace-id header) and the target workspace (from the URL path) are validated independently rather than enforceably bound together. The ability layer grants VIEW_TABLES, VIEW_TABLE, and JOIN_TABLES permissions based solely on the header-derived identity, completely ignoring the path parameter. An authenticated user can enumerate, read, and modify data across all tenants in the system by manipulating the organizationId in the URL. The root cause is architectural, not codical. JwtAuthGuard validates that the user is legitimate; the ability layer determines what they can do; but no component owns the invariant that these two identifiers must agree. This is the fossil record of a platform that evolved from single-tenant to multi-tenant: the ability vocabulary (VIEW_TABLES, JOIN_TABLES) was coined when organizational context was implicit, and when :organizationId was added to paths, neither the ability definitions nor the permission logic was restructured to require organizational binding. The fix in version 3.20.207-lts presumably enforces consistency at the controller layer. However, note that controller-layer patches are the modal fix for this vulnerability class — approximately 70% of multi-source identity binding failures get resolved at the entry point rather than at the ability-layer decision logic. If the ability definitions remain unchanged (VIEW_TABLES still grants unbounded cross-tenant access), any future code path that queries the ability layer directly inherits the original flaw. This creates semantic sediment: the ability definitions encode permissions that no longer match their runtime enforcement, setting up future security reviews to reconstruct the wrong threat model. The severity is systematically underweighted by CVSS 5.9. The ability to join tables across organizational boundaries enables inferential exfiltration — correlating join keys across tenants to detect whether specific people or relationships exist in other organizations. This is data synthesis, not merely data disclosure. If you are defending a multi-tenant platform that grew from single-tenant roots, audit your ability or permission definitions for any resource-access permissions that lack organizational context as a first-class parameter. If organizational context is not encoded in the ability definition itself, every consumer of that permission is tenant-unbound by default. The fix is not 'check your inputs' — it is ensuring that authorization context is structural, not additive.

Reviewed through automated stages and approved by a human before publication.