CVE-2026-82874 in ToolJet
Summary
by MITRE • 08/31/2026
ToolJet before v3.16.208 fails to validate that authenticated users belong to the organization specified in the organizationId path parameter of tooljet-db endpoints, allowing any Builder user to read, modify, and delete tables across tenant boundaries. Attackers can extract victim organization IDs from public app endpoints, then exploit schema operation endpoints to disclose table schemas, plant malicious tables, corrupt existing schemas, or permanently destroy victim data without any relationship to the target organization.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified in ToolJet versions prior to 3.16.208 represents a critical failure in access control mechanisms within the application's database management layer. Specifically, the tooljet-db endpoints fail to perform adequate validation of the authenticated user's organizational affiliation against the organization identifier provided in the request path parameter known as organizationId. This architectural flaw effectively decouples authentication from authorization for these specific administrative operations. While the system correctly verifies that a user is logged in and possesses Builder-level permissions within their own context, it blindly trusts the organizationId supplied by the client-side application without cross-referencing this value against the actual tenant association of the authenticated session. This lack of server-side validation allows an attacker to manipulate API requests to target resources belonging to different tenants or organizations within the multi-tenant architecture.
From a technical perspective, this flaw constitutes an Insecure Direct Object Reference (IDOR) vulnerability, which is categorized under CWE-639 in the Common Weakness Enumeration standards. The core issue lies in the assumption that the client-provided identifier accurately reflects the authorized scope of the current user's session. By exploiting this trust boundary violation, a malicious actor with Builder privileges can craft HTTP requests targeting arbitrary organization identifiers. Since the backend processes these requests without verifying whether the requesting user is actually a member or administrator of the targeted organizationId, the system grants access to database schemas and data that should remain isolated within their respective tenant boundaries. This breaks the fundamental principle of multi-tenancy isolation, where data belonging to one customer must be strictly inaccessible to users from other customers unless explicitly shared through secure mechanisms.
The operational impact of this vulnerability is severe due to the high level of privileges associated with Builder roles in ToolJet. An attacker can leverage schema operation endpoints to perform a variety of destructive and exfiltrative actions against victim organizations. First, they can read table schemas to understand the data structure of the target organization, facilitating further targeted attacks or social engineering efforts based on known data types. Second, attackers can modify existing tables by altering column definitions, adding constraints, or changing data types, which may lead to application instability or logic errors for legitimate users. Third, and most critically, they can delete entire tables or corrupt schema metadata, resulting in the permanent loss of critical business data. This capability allows an attacker to disrupt service availability and integrity without needing prior knowledge of specific internal IDs beyond what is publicly exposed through app endpoints.
Attackers typically initiate this exploitation by enumerating valid organization identifiers from public-facing application endpoints where such information might be inadvertently disclosed or easily guessed due to sequential ID patterns. Once a target organizationId is identified, the attacker constructs malicious API calls that include their own authenticated session token but specify the victim's organizationId in the path parameter. The server processes these requests as if they originated from within the correct context, thereby executing commands against the wrong tenant's database. This process requires no additional authentication bypass or privilege escalation beyond having a valid Builder account on any platform instance, making it relatively easy to exploit for anyone with access to the application interface.
To mitigate this vulnerability and prevent similar issues in future releases, developers must implement strict server-side authorization checks that validate the authenticated user's membership within the organization specified by the request parameters. This involves querying the database relationship tables to confirm that the current session's userId is linked to the target organizationId before executing any schema modification or data access operations. Additionally, implementing role-based access control (RBAC) policies at the API gateway level can help enforce these boundaries more robustly. Organizations running affected versions should immediately upgrade to version 3.16.208 or later where this validation logic has been corrected. Until an update is applied, administrators should monitor logs for unusual schema modification patterns and restrict Builder role assignments to only those users who strictly require such elevated privileges within their specific organizational context.
This vulnerability aligns with the MITRE ATT&CK technique T1530, which covers Data from Information Repositories, as it allows unauthorized access to stored data across tenant boundaries. It also reflects aspects of T1485, Data Destruction, given the potential for permanent deletion of tables and corruption of schemas. The failure represents a classic case where authentication is present but authorization logic is flawed, highlighting the importance of validating all input parameters against user context regardless of their source. Ensuring that every API endpoint enforces strict tenant isolation checks is essential for maintaining data integrity in multi-tenant SaaS environments like ToolJet.