ToolJet Cross-Tenant IDOR in ToolJet Database API Exposes AI Agent/Workflow Data

Technical Analysis

The vulnerability stems from an authorization gap: JwtAuthGuard validates that the tj-workspace-id header corresponds to a workspace the caller belongs to, but the CASL-based ability checks in ability/index.ts grant VIEW_TABLES, VIEW_TABLE, and JOIN_TABLES without binding those permissions to the :organizationId value in the request path. An authenticated attacker can send their own valid tj-workspace-id while specifying a different victim organizationId in endpoints like GET /api/tooljet-db/organizations/:organizationId/tables or POST /api/tooljet-db/organizations/:organizationId/join, bypassing tenant isolation. This allows disclosure of table names, schemas, and row data, and abuse of table-management routes to create, alter, bulk-populate, or drop tables in another tenant's database. Because ToolJet is used to build and deploy internal AI agents and workflows, cross-tenant data exposure or corruption at this layer can poison the data sources, tool outputs, or retrieval context that downstream agents rely on, effectively enabling a form of indirect data/tool poisoning across tenant boundaries.

Affected Systems

ToolJet

Detection Signatures

• HTTP requests to /api/tooljet-db/organizations/:organizationId/* where organizationId does not match the caller's own workspace/organization membership derived from tj-workspace-id
• Repeated enumeration of sequential or guessed organizationId values against tooljet-db endpoints
• Unexpected VIEW_TABLES, VIEW_TABLE, JOIN_TABLES, table-create, table-alter, or table-drop calls originating from accounts with no legitimate business relationship to the target organizationId
• Audit logs showing cross-tenant table schema or row access shortly after authentication

Remediation Steps

1. 1

   Upgrade ToolJet

   Update to ToolJet version 3.20.207-lts or later, which fixes the authorization binding issue.

2. 2

   Enforce path-to-session organization binding

   Ensure all ToolJet Database API handlers verify that the :organizationId in the URL matches the organization derived from the authenticated session/tj-workspace-id before evaluating CASL abilities, not just at the JwtAuthGuard layer.

3. 3

   Audit cross-tenant access logs

   Review historical API logs for requests where organizationId in the path diverges from the caller's known workspace membership to identify potential prior exploitation.

4. 4

   Apply least-privilege tenant isolation

   For multi-tenant deployments feeding AI agents/workflows, add defense-in-depth checks (e.g., database-level row/tenant isolation, WAF rules) so a single authorization bug cannot expose all tenant data.

5. 5

   Rotate and review affected data

   If exploitation is suspected, rotate credentials/secrets stored in exposed tables and review data used by agents/workflows for tampering.