ToolJet EUVD-2026-112390

Exploitation requires a ToolJet instance on an affected version (greater than 3.20.1-lts and before 3.20.242-lts) that has instance-level signup DISABLED in instance settings and has a default workspace present - these are the exact preconditions in the vendor PoC. The flaw is only meaningful under this disabled-signup configuration; instances that leave signup enabled are behaving as intended and are not affected by this bypass. No authentication, user interaction, or special network position is needed (PR:N/UI:N/AV:N). The realistic impact is limited by the permissions granted to a newly created ordinary member of the default workspace, so risk scales with how much that workspace exposes to default members.

The input CVSS 4.0 score is 6.9 (medium) with vector AV:N/AC:L/AT:N/PR:N/UI:N and vulnerable-system impact VC:L/VI:L/VA:N, i.e. network-reachable, low-complexity, unauthenticated exploitation yielding limited confidentiality and integrity impact. The vuln.today decision label is 'this_month' - a real but non-emergency priority, consistent with the medium CVSS and the fact that impact is bounded to whatever an ordinary member of the default workspace can access. No EPSS probability was provided in the input and the CVE is not listed in CISA KEV, so there is no signal of active or widespread exploitation; these signals are MISSING rather than low. A step-by-step proof-of-concept is published in the ToolJet GHSA advisory, but it is an advisory reference, not verified working exploit code. The key limiting factor that tempers the CVSS vector is that this bug is only exploitable on instances where an administrator has explicitly DISABLED instance-level signup - on default/open-signup instances the behaviour is intended, so the real-world exposed population is the subset of ToolJet operators who deliberately locked signup down and are on an affected version.

An administrator disables instance-level signup to keep a self-hosted ToolJet instance closed, but the SignupDisableGuard treats the setting string 'false' as truthy and still permits signup. An unauthenticated attacker sends a POST to /api/signup with just an email and password and no organizationId; the server creates the account, auto-joins it to the default workspace, and returns a valid session token. A proof-of-concept with exact request steps exists in the GHSA advisory, but it is an advisory reference and is not verified as working exploit code.