CVE-2026-92788 in Coze Studio
Summary
by MITRE • 09/16/2026
Coze Studio through 0.5.1 fails to validate that table names in workflow SQL customization nodes belong to the caller's workspace. Authenticated attackers can enumerate predictable table identifiers and execute SQL statements against other workspaces' memory databases to read, insert, or delete data.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in Coze Studio versions through 0.5.1 represents a critical failure in access control mechanisms within the application's workflow engine, specifically affecting nodes that allow for custom SQL execution. This flaw stems from an insufficient validation of input parameters related to database table names. When users configure workflows with SQL customization nodes, the system accepts user-supplied identifiers for target tables but fails to verify whether these tables reside within the workspace context authorized by the currently authenticated caller. In multi-tenant or workspace-isolated architectures, such as those employed by Coze Studio to separate data between different teams or projects, this oversight creates a direct path for unauthorized cross-workspace data access. The core technical deficiency lies in the backend logic that processes these SQL queries; rather than enforcing strict scoping rules based on the user's session context and workspace permissions, the application blindly executes the provided table name against the underlying memory database infrastructure without checking ownership or isolation boundaries.
From a technical perspective, this vulnerability is classified as an Insecure Direct Object Reference (IDOR) combined with SQL Injection capabilities due to the nature of the input being executed directly in a query structure. The predictability of the table identifiers exacerbates the risk significantly. Because the database schema and naming conventions are often consistent across workspaces or follow a predictable pattern, authenticated attackers can easily enumerate valid table names from their own workspace and then attempt to access corresponding tables in other workspaces by simply altering the identifier in the SQL statement. This allows for precise targeting of specific data stores without needing complex injection techniques to discover structure, as the structural integrity is assumed rather than validated against permission sets. The lack of validation means that any authenticated user can craft a malicious workflow node pointing to resources they do not own, effectively bypassing logical access controls designed to maintain tenant isolation.
The operational impact of this vulnerability is severe, particularly regarding data confidentiality and integrity within collaborative platforms. An attacker with valid credentials for one workspace can read sensitive information stored in other workspaces' memory databases, leading to significant data breaches that may include proprietary business logic, customer details, or internal communications depending on the organization's usage patterns. Furthermore, the ability to insert or delete data introduces risks of data corruption and integrity loss. Malicious actors could inject false records into shared systems or purge critical historical data from competitor workspaces if they can identify them, potentially disrupting operations or causing financial harm. This level of access undermines the fundamental trust model of multi-tenant applications where users expect their workspace's data to remain isolated from others unless explicitly shared through approved mechanisms.
To mitigate this vulnerability, immediate remediation should focus on implementing strict server-side validation for all SQL-related inputs within workflow nodes. Developers must enforce a whitelist approach or rigorous schema mapping that ties every table reference back to the authenticated user's specific workspace ID before query execution. It is essential to ensure that database queries are scoped using tenant identifiers injected by the application layer, rather than relying on client-supplied values alone. Additionally, implementing parameterized queries where possible can help prevent broader SQL injection vectors, although in this case, the primary issue is logical access control rather than syntax manipulation. Security testing should include rigorous cross-workspace penetration tests to verify that isolation boundaries are respected under all conditions. Organizations using affected versions must upgrade to a patched release immediately and review existing workflows for any custom SQL nodes that might be exploited until patches are applied. Monitoring logs for unusual patterns of database access across different workspace IDs can also help detect ongoing exploitation attempts in real-time. This incident highlights the critical importance of validating not just input format but also contextual authorization when handling dynamic data operations in multi-tenant environments, aligning with industry standards such as CWE-602 (Client-Side Enforcement of Server-Side Access Control) and ATT&CK techniques related to Data Staged or Unsecured Credentials if credentials were compromised to facilitate the initial access.