A developer in one Lowcoder organization can run another organization’s saved library query on the same instance. CERT/CC’s October 13 vulnerability note describes missing organization checks in the Query Library API. On a multi-tenant deployment, the query can return data from the other organization’s backend source. CERT/CC confirmed the flaw in 2.4.10 and names CVE-2026-16753.
The attacker needs a signed-in admin or dev role in their own organization. That condition is easier to meet on instances where LOWCODER_EMAIL_SIGNUP_ENABLED and LOWCODER_CREATE_WORKSPACE_ON_SIGNUP are both TRUE: CERT/CC says a self-signup account receives one of those roles by default. For shared customer instances, restrict the affected API and inventory the accounts that can reach Query Library.
A role check misses ownership
Query Library stores reusable queries and data-source references for a workspace. Lowcoder checks that the requester has an admin or dev role in the requester’s organization, but CERT/CC says the LibraryQuery API’s metadata-retrieval and query-execution endpoints omit the check that the requested query belongs to that same organization. A valid role in tenant A can therefore reach tenant B’s saved query. The shared instance accepts a role from the requester’s tenant when it should also match the saved query’s owner.
The metadata route exposes the full Domain Specific Language (DSL) of another organization’s library query, its complete configuration and each referenced datasourceId. The execution route runs an available query and returns its response from the affected organization’s backend data source. CERT/CC also identifies possible modification, destruction and paid-source cost abuse, depending on what those queries can do. It describes the operator’s problem plainly: “By bypassing organization-level authorization, Lowcoder instances effectively function as shared environments for attackers.”
The CVE Program’s JSON record scopes the affected versions from 2.1.0 through 2.4.10 and describes the execution endpoint. CERT/CC’s vulnerability note additionally documents metadata retrieval, and its test confirmed 2.4.10. Check the running version and the Query Library feature in each shared deployment; use the broader two-endpoint note to plan containment.
Self-signup changes the access pool
Inspect whether the instance hosts more than one organization and whether both signup settings are TRUE. Record who holds admin and dev roles in each organization, including accounts created through self-signup. A default privileged role gives a new self-signup account the prerequisite CERT/CC names; an existing privileged account can meet it even after signup is closed. Trace Query Library access in available application and ingress logs when investigating a suspected cross-tenant query. CERT/CC publishes no request signature or confirmed intrusion indicator for this flaw, so concentrate first on reachable endpoints, role assignments and the data sources behind saved queries.
CERT/CC says it could not reach Lowcoder for coordinated disclosure, and its vendor entry remains Unknown with no vendor statement. The note directs administrators to restrict the affected API “until an official security update is available.” The note identifies no fixed build.
Restrict the shared query routes
Restrict access to Query Library metadata retrieval and execution at the application or ingress layer for shared instances, even if that interrupts the feature for some users. Limit application access to trusted users and reduce admin and dev assignments to those who need them. Where customers require separate trust domains, place their organizations on separate Lowcoder instances; that removes the cross-organization path through a shared application. If your team can change the source, enforce organization ownership for both resource lookup and execution as CERT/CC recommends.
Verify the change at the route and account level: identify the deployed Lowcoder version, confirm both affected operations are subject to the intended restriction, and use an authorized test account to confirm a user outside the permitted access group is denied Query Library access. Review the two signup settings and privileged-role inventory again after restricting access, because disabling signup alone leaves existing accounts in place. The saved query is the asset here; put the ownership check or isolation around it before another tenant gets to ask it for data.