CVE-2026-73068 in ToolJet
Summary
by MITRE • 08/11/2026
ToolJet is the open-source foundation am AI-native platform for building and deploying internal tools, workflows and AI agents. Prior to 3.20.207, the ToolJet Database HTTP API in server/src/modules/tooljet-db/controller.ts authorizes operations against the :organizationId URL path value without verifying that the caller belongs to that organization. JwtAuthGuard validates the tj-workspace-id header against the caller's memberships, while server/src/modules/tooljet-db/ability/index.ts grants VIEW_TABLES, VIEW_TABLE, and JOIN_TABLES without binding them to the path organization. An authenticated user can set tj-workspace-id to the user's own workspace and target another workspace through GET /api/tooljet-db/organizations/:organizationId/tables, GET /api/tooljet-db/organizations/:organizationId/table/:tableName, POST /api/tooljet-db/organizations/:organizationId/join, and the related table-management routes, allowing disclosure of table names, schemas, and rows and allowing tables to be created, altered, bulk populated, or dropped across tenant boundaries. This issue is fixed in version 3.20.207-lts.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/11/2026
The vulnerability exists within ToolJet's database HTTP API implementation where insufficient authorization checks allow cross-tenant data access through manipulated URL path parameters. The flaw specifically resides in server/src/modules/tooljet-db/controller.ts where the :organizationId parameter from URL paths is not validated against the authenticated user's organizational membership. While JwtAuthGuard correctly validates the tj-workspace-id header against caller memberships, the authorization logic in server/src/modules/tooljet-db/ability/index.ts fails to bind VIEW_TABLES, VIEW_TABLE, and JOIN_TABLES permissions to the path organization context. This design gap creates a privilege escalation vulnerability where authenticated users can manipulate the tj-workspace-id header to reference their own workspace while targeting tables from other organizations through specific API endpoints.
The technical exploitation occurs through several HTTP methods including GET requests to /api/tooljet-db/organizations/:organizationId/tables and /api/tooljet-db/organizations/:organizationId/table/:tableName, as well as POST requests to /api/tooljet-db/organizations/:organizationId/join and related table management routes. Attackers can leverage this vulnerability to discover table names, schemas, and row data from organizations they do not belong to, while simultaneously gaining the ability to create, modify, bulk populate, or destroy database tables across tenant boundaries. This represents a critical authorization bypass that violates fundamental multi-tenancy security principles.
The operational impact of this vulnerability is severe as it enables unauthorized data disclosure and modification across different organizational tenants within the same ToolJet instance. An attacker with access to any valid user account can potentially extract sensitive information from other organizations, modify database structures, or even delete critical tables belonging to different tenants. This cross-tenant data exposure constitutes a significant breach of data isolation and confidentiality requirements that are essential in multi-tenant SaaS environments.
This vulnerability maps to CWE-285 (Improper Authorization) and aligns with ATT&CK technique T1078 (Valid Accounts) and T1566 (Phishing) as attackers may use legitimate credentials to exploit the authorization gap. The issue demonstrates poor least privilege enforcement and inadequate input validation of path parameters, creating a pathway for privilege escalation through manipulated API calls. Organizations using ToolJet versions prior to 3.20.207 should immediately implement mitigations including immediate patching, monitoring for suspicious API access patterns, and implementing additional authorization layers to prevent cross-tenant data access. The fix in version 3.20.207-lts addresses this by properly binding authorization permissions to the organization context specified in URL paths, ensuring that users can only access database resources within their authorized organizational boundaries.