Description

ToolJet through 3.0.0-ee-beta.2 contains authorization bypass vulnerabilities in the POST /api/v2/resources/export endpoint that allow authenticated users to disclose TooljetDB table schemas across workspace boundaries and export app definitions across granular permission boundaries. Attackers can supply a body-provided organization_id parameter to access schemas from other workspaces, or bypass per-app authorization gates to export restricted app definitions within their workspace.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.0",
  "pubDate": "2026-08-31T09:17:08.310Z",
  "pubdate": "2026-08-31T09:17:08.310Z",
  "executiveSummary": "ToolJet versions up to 3.0.0-ee-beta.2 are susceptible to critical authorization bypass vulnerabilities within the POST /api/v2/resources/export endpoint. This security flaw allows authenticated users to circumvent established access control mechanisms, leading to unauthorized data disclosure and resource exportation.\nThe vulnerability manifests as an Insecure Direct Object Reference (IDOR) and broken function-level authorization. Attackers can manipulate input parameters to bypass workspace boundaries, facilitating the unauthorized retrieval of ToolJetDB table schemas from external organizations. Furthermore, the flaw permits the unauthorized export of application definitions, effectively overriding granular permissions configured within the platform.\nThe risk implication is significant, as it enables lateral movement and data exfiltration across isolated environments. Exploitation requires an authenticated session but leverages the lack of server-side validation to target resources the user is not authorized to access. This compromise threatens the confidentiality and integrity of proprietary organizational data and application configurations managed within the ToolJet environment.",
  "technicalDetails": "The vulnerability resides within the request handling logic of the POST /api/v2/resources/export endpoint. The root cause is the server's failure to strictly validate that the requested resource identifier and the associated organization context align with the session-based authorization token of the caller.\nSpecifically, the application improperly trusts client-supplied parameters, such as the organization_id, during the resource export process. By injecting a target organization_id into the request body, an attacker can coerce the API to process data outside of their own security perimeter. Because the backend service does not perform an effective server-side check against the authenticated user's workspace memberships, the system processes the request as if it originated from a privileged context within the target organization.\nThe attack flow follows a predictable pattern: 1) The attacker authenticates as a legitimate user within a workspace. 2) The attacker intercepts a call to the /api/v2/resources/export endpoint. 3) The attacker modifies the payload to include a target organization_id that they do not belong to or provides an identifier for a restricted application that they do not possess permissions to export. 4) The server processes the malicious payload and returns the sensitive ToolJetDB schema or application definitions in the HTTP response.\nIn addition to cross-workspace schema disclosure, the vulnerability allows for the circumvention of granular permission gates. Even within an authorized workspace, users restricted from specific application configurations can export restricted definitions by exploiting the same flawed validation logic that ignores the granular access control lists (ACLs) governing export capabilities. This indicates a systemic failure in the authorization middleware protecting the export handler.\nThe affected component is the internal API export controller responsible for resource serialization. Because the vulnerability is based on logic errors rather than injection vulnerabilities like SQLi, it is highly reliable and does not require complex payload crafting, merely precise manipulation of the JSON body. The scope of impact includes the total loss of confidentiality regarding database structures and intellectual property contained within app definitions, potentially exposing hardcoded secrets, data models, or logic flows to unauthorized parties."
}