ToolJet: Instance-level signup bypass when signup is disabled

Summary

SignupDisableGuard incorrectly treated the signup setting as a boolean. Because the setting was returned as the string 'true' or 'false', the value 'false' evaluated as truthy in JavaScript. As a result, unauthenticated users could create accounts through the signup API even when instance-level signup was disabled.

Details

The guard retrieved the signup setting through getSettings(), which returned the raw database column value as a string. It then authorized the request using logic equivalent to:

return request.body.organizationId || enableSignUp;

When signup was disabled, enableSignUp contained the string 'false'. Since any non-empty string is truthy in JavaScript, this expression permitted signup requests without an organizationId. The login-page UI correctly hid or disabled signup based on the configured toggle, but the corresponding server-side API restriction was ineffective. Accounts created through the exposed API were automatically added to the default workspace, and a successful signup response included a valid session token.

Proof of concept

Prerequisites:

• Run ToolJet.
• Disable instance-level signup in the instance settings.
• Ensure a default workspace exists.

Send an unauthenticated request directly to the instance-level signup endpoint, omitting organizationId:

POST /api/signup Content-Type: application/json

{ "email": "attacker@example.com", "password": "ExamplePassword123!" }

Despite signup being disabled, the API creates the user, automatically adds the account to the default workspace, and returns a valid session token. Verify that the new credentials or returned token can be used to authenticate and access resources available to a newly joined member of the default workspace.

Impact

An unauthenticated remote attacker could bypass an administrator’s signup restriction and create an account on an affected instance. The account would be automatically joined to the default workspace and immediately receive an authenticated session. This could allow unauthorized access to workspace resources available to ordinary members, including applications, data, or functionality exposed under the default workspace’s permissions. The precise confidentiality and integrity impact depends on the workspace configuration and the privileges granted to newly created users.