CVE-2026-77935 in Studio
Summary
by MITRE • 10/20/2026
Coze Studio through 0.5.1 contains an insecure direct object reference vulnerability in workflow.go that allows authenticated users to access other spaces' workflows by supplying foreign workflowIDs. Attackers can pair their own spaceID with another tenant's workflowID in save, update_meta, batch_delete, canvas, test_run and nodeDebug routes to read, run, overwrite or delete workflows.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified in Coze Studio versions up to 0.5.1 represents a critical failure in access control mechanisms, specifically classified as an Insecure Direct Object Reference (IDOR) within the application's workflow management module. This flaw resides primarily in the workflow.go component and stems from insufficient server-side validation of object ownership during API interactions. The core technical deficiency lies in the system's reliance on client-supplied identifiers without verifying that the requesting authenticated user possesses legitimate authorization for the specific resource being accessed. By manipulating the spaceID parameter to match their own tenant identifier while retaining a foreign workflowID belonging to another organization, attackers can bypass logical access controls. This manipulation is effective across multiple endpoints including save, update_meta, batch_delete, canvas retrieval, test_run execution, and nodeDebug operations, indicating a systemic lack of authorization checks throughout the workflow lifecycle management functions rather than an isolated incident in a single function.
From a technical perspective, this vulnerability exploits the assumption that valid authentication implies permission for all referenced resources within the session context. In secure architectures, every request involving a specific resource ID must undergo an explicit check to ensure the user's role and permissions align with the ownership of that resource. Here, the application fails to enforce multi-tenancy boundaries effectively at the API layer. When an authenticated user submits a request containing their own spaceID alongside another tenant's workflowID, the backend processes the action as if it were legitimate because the primary authentication token is valid. The absence of secondary authorization logic allows the attacker to read sensitive workflow configurations, execute potentially malicious automation scripts via test_run or canvas interactions, overwrite critical business logic through update_meta and save operations, or permanently destroy data using batch_delete. This lack of isolation between tenant spaces undermines the fundamental security principle of least privilege and multi-tenant integrity.
The operational impact of this vulnerability is severe due to its potential for both information disclosure and remote code execution implications depending on the nature of the workflows involved. Attackers can exfiltrate proprietary business logic, intellectual property, or sensitive data embedded within workflow definitions by reading other tenants' configurations. Furthermore, the ability to overwrite workflows allows an attacker to inject malicious scripts that could compromise downstream systems when those workflows are executed in production environments. The capability to delete workflows results in denial of service for legitimate users and potential loss of critical business continuity assets. Since these actions require only authentication, which is often easier to obtain or maintain than unauthenticated access, the risk surface is significantly expanded. This vulnerability aligns with CWE-639 (Authorization Bypass Through User-Controlled Key) as it involves bypassing authorization by manipulating a key parameter that identifies an object. Additionally, from a threat modeling perspective using MITRE ATT&CK frameworks, this behavior maps to T1078 Valid Accounts and potentially T1496 Remote Service Abuse if the workflows are used to interact with external services or execute commands on connected infrastructure.
Mitigation strategies must focus on implementing robust server-side authorization checks for all endpoints involved in workflow management. Developers should enforce strict ownership verification by ensuring that every request validates not only the user's authentication status but also their explicit permission to access, modify, or delete the specific resource identified by the workflowID and spaceID combination. This can be achieved by querying a secure database relationship table that maps users to authorized spaces and workflows before processing any state-changing requests. Additionally, implementing unique identifiers for resources rather than relying solely on sequential or predictable IDs can reduce enumeration risks, though it does not replace proper authorization checks. Input validation should also ensure that the spaceID provided in the request matches the context of the authenticated user's session. Regular security audits and static code analysis focused on access control logic are recommended to detect similar flaws across other modules. Updating to a patched version where these logical flaws have been resolved is essential for immediate remediation, alongside monitoring logs for anomalous patterns such as rapid cross-tenant resource accesses which may indicate active exploitation attempts.