CVE-2026-55583
Summary
by MITRE • 06/24/2026
Twenty is an open-source CRM (customer relationship management) platform. Prior to 2.9.0, Twenty was vulnerable to a cross-workspace insecure direct object reference (IDOR) in the AI agent monitor's AgentTurnResolver, in packages/twenty-server/src/engine/metadata-modules/ai/ai-agent-monitor/reso lvers/agent-turn.resolver.ts. The agentTurns(agentId) query and the evaluateAgentTurn(turnId) mutation looked up rows by agentId or id only; although AgentTurnEntity has a workspaceId column, it was not included in the WHERE clause, and the class-level guards only checked that the caller was authenticated in some workspace rather than that the requested object belonged to it, with the same flaw present in agent-turn-grader.service.ts. As a result, any authenticated user with the AI settings flag, a workspace owner by default, could target any other workspace on the same instance given the victim's agentId or turnId: agentTurns returned the victim's full chat history including message parts such as raw chat text, tool calls, and tool outputs, while evaluateAgentTurn inserted an agentTurnEvaluation row with the victim's workspaceId and fed the victim's turn into the default LLM. The agentId and turnId are non-guessable UUIDs but are exposed in the URL of the settings page. This issue is fixed in version 2.9.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 06/24/2026
The vulnerability resides within Twenty's AI agent monitoring functionality, specifically in the AgentTurnResolver component that handles queries related to agent interactions and evaluations. This represents a classic insecure direct object reference flaw where the application fails to properly validate authorization before accessing resources. The technical implementation demonstrates a fundamental failure in access control enforcement where the system relies on user authentication alone rather than proper workspace isolation. The vulnerability affects the agentTurns query and evaluateAgentTurn mutation, both of which operate on the AgentTurnEntity without incorporating workspace validation into their database queries.
The core flaw stems from the absence of workspaceId filtering in the WHERE clause when retrieving agent turn data, combined with insufficient class-level guards that only verify user authentication within any workspace rather than confirming that the requested resource belongs to the authenticated user's workspace. This architectural oversight allows malicious actors to bypass normal access controls through simple parameter manipulation. The vulnerability is particularly concerning because it affects critical AI functionality where sensitive conversation data flows through the system, including raw chat text, tool calls, and tool outputs that may contain proprietary information or personal data.
The operational impact of this vulnerability extends beyond simple data exposure to include potential manipulation of AI evaluation processes. An attacker with knowledge of a target workspace's agentId or turnId could access complete chat histories from other workspaces, potentially exposing confidential business communications, customer interactions, or sensitive operational data. Additionally, the evaluateAgentTurn mutation creates a more dangerous scenario where an attacker could insert malicious evaluations into another workspace's agent turn records while feeding that workspace's conversation data to the default language model, potentially corrupting AI decision-making processes or creating false evaluation results.
This vulnerability aligns with CWE-639: Authorization Bypass Through User-Controlled Key and maps to ATT&CK technique T1566.002 for initial access through credential compromise, though in this case the attack vector is more subtle through exposed identifiers. The issue demonstrates poor principle of least privilege implementation where authenticated users have access to all workspaces rather than being restricted to their own workspace boundaries. The non-guessable UUIDs exposed in URLs create an additional attack surface where attackers can discover valid identifiers through reconnaissance activities, making the exploitation more straightforward than if the identifiers were truly random or hidden.
The fix implemented in version 2.9.0 addresses these fundamental access control issues by properly incorporating workspace validation into the database queries and strengthening the authorization checks to ensure that all operations are scoped to the authenticated user's workspace. This requires modifications to the agent-turn.resolver.ts and agent-turn-grader.service.ts files to include workspaceId conditions in WHERE clauses and implement proper access control guards that validate both authentication status and resource ownership. The remediation approach follows standard security best practices for multi-tenant applications where proper isolation between workspaces is essential for maintaining data confidentiality and integrity across different organizational boundaries.
Organizations using Twenty should immediately assess their deployment for this vulnerability and ensure all instances are upgraded to version 2.9.0 or later. Security teams should also implement monitoring for unusual patterns in AI agent usage that might indicate exploitation attempts, particularly around the specific endpoints affected by this vulnerability. The incident highlights the importance of comprehensive security testing for multi-tenant applications where workspace boundaries must be strictly enforced at all levels of the application stack to prevent cross-workspace data leakage and manipulation.