CVE-2026-77935: Cross-Space Workflow IDOR via Insufficient Resource Authorization
A flaw in Coze Studio's workflow API checks that the caller belongs to the space they name, but not that the workflow they target belongs to that space. Any authenticated user can read, run, modify or delete other spaces' workflows, including their canvas designs, node configurations and prompt templates.
Overview
Coze Studio is an open-source AI agent development platform with visual tools for building, debugging and deploying agents. Workspaces are separated into spaces, and the workflow handlers check that the caller is a member of the spaceID in the request.
They never check that the workflowID in the same request belongs to that space. Because the caller supplies both values, any authenticated user can pass their own spaceID together with another space's workflowID and test-run, read, save, update or delete that workflow. The flaw is independent of the code runner and affects every deployment configuration, including the hardened production default
Because any authenticated Coze Studio user can read, overwrite or delete workflows in other spaces just by supplying their workflow IDs, in every deployment configuration including the hardened production default, multi-space deployments should apply the fix as soon as it is available.
Affected Product
Affected Files
- backend/application/workflow/workflow.go (lines 316-320, 342-348, 410-421, 448-457, 527-582, 585-647)
Root Cause
Multiple workflow handlers validate that the authenticated caller is a member of the supplied spaceID via checkUserSpace(), but do not verify that the target workflowID belongs to that space.
Because workflowID is entirely caller-supplied and the only check performed is space membership, any authenticated user can read, modify, or delete workflows owned by other spaces by supplying an arbitrary workflowID with their own spaceID.
PoC
1. Authenticate as a user in Space A. Obtain a valid workflowID belonging to Space B (enumerable via predictable ID patterns or prior knowledge).
2. Send a TestRun request with spaceID set to Space A and workflowID set to the target workflow in Space B:
POST /api/workflow/testrun
{ "spaceID": "<space_A_id>", "workflowID": "<space_B_workflow_id>", ...}
3. The server calls checkUserSpace(ctx, uid, spaceA) (passes — caller is a member of Space A), then dispatches execution against the Space B workflow without further authorization.
Affected operations: TestRun, NodeDebug, GetCanvasInfo, SaveWorkflow, UpdateWorkflowMeta, BatchDeleteWorkflow.
Relevant code pattern across all affected handlers:
// checkUserSpace validates caller membership in spaceID only
if err := checkUserSpace(ctx, ctxutil.MustGetUIDFromCtx(ctx), mustParseInt64(req.GetSpaceID())); err != nil {
return nil, err
}
// WorkflowID is then used directly without ownership
checkGetWorkflowDomainSVC().Save(ctx, mustParseInt64(req.WorkflowID),
req.GetSchema())
Impact
Any authenticated user can read, overwrite, or delete workflows belonging to other spaces. This breaks tenant isolation across all coze-studio deployment configurations, including the hardened production default.
An attacker with a valid account in any space can exfiltrate workflow designs (canvas schemas, node configurations, prompt templates) from other tenants and modify or destroy their workflows. The affected handlers cover the full CRUD surface of the workflow canvas editor.
Suggested Remediation
After validating space membership, fetch the target workflow and verify its SpaceID matches the authorized space before proceeding. The correct pattern is implemented in the same codebase at workflow.go:1551-1565 (OpenAPI WorkflowRun) and single_agent.go:531-557.
Additional Resources
- CVE-2026-77935 record
