CVE-2026-105763 in Twenty
Summary
by MITRE • 10/06/2026
Twenty is an open-source CRM (customer relationship management) platform. From 1.20.10 until 2.7.0, the /metadata GraphQL connectedAccounts query returned connectionParameters from ConnectedAccountDTO for every connected account in a workspace, including plaintext IMAP, SMTP, and CalDAV passwords, because the field was not hidden and the lookup did not enforce the calling user's identity or account visibility. A normal workspace member could obtain other members' external-service credentials and use them to access mail or calendars and potentially reset third-party accounts. Google and Microsoft OAuth-only workspaces were not affected. This issue is fixed in version 2.7.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified within the Twenty open-source customer relationship management platform represents a critical failure in data exposure controls, specifically affecting versions ranging from 1.20.10 through 2.7.0. The core of this issue lies in the implementation of the /metadata GraphQL endpoint, which is designed to provide metadata about connected accounts for workspace integration purposes. However, the query logic failed to implement proper access control mechanisms when retrieving connection parameters associated with ConnectedAccountDTO objects. Instead of restricting data retrieval based on user identity or account visibility permissions, the system returned sensitive configuration details for every connected account within a given workspace, regardless of which authenticated user initiated the request. This architectural oversight allowed any standard workspace member, who typically possesses limited privileges such as viewing basic contact information or managing their own tasks, to access deeply privileged data belonging to other users in the same organizational unit.
The technical flaw centers on an improper authorization check within the GraphQL resolver for connected accounts. When a user queries this endpoint, the backend processes the request and fetches connection parameters including plaintext passwords required for IMAP, SMTP, and CalDAV protocols without verifying whether the requesting user has permission to view that specific account's details. This lack of enforcement means that authentication credentials are transmitted in cleartext over the network if HTTPS is not strictly enforced at the proxy level, but more critically, they are exposed within the application logic itself. The absence of identity-based filtering implies that the system treats all connected accounts as publicly accessible metadata rather than sensitive private data tied to specific user identities. This design error effectively bypasses the principle of least privilege, granting lower-level users access to high-sensitivity credentials without any form of administrative approval or contextual validation.
The operational impact of this vulnerability is severe and multifaceted. By obtaining plaintext passwords for email (IMAP/SMTP) and calendar (CalDAV) services, an attacker with a standard workspace account can impersonate other colleagues. This capability allows the adversary to read private communications, access sensitive business intelligence contained in emails, and manipulate shared calendars to disrupt operations or schedule malicious events. Beyond immediate data exfiltration, these credentials provide a foothold for further attacks such as phishing campaigns using trusted sender addresses, which significantly increases their success rate due to perceived legitimacy. Furthermore, if users reuse passwords across third-party services, the attacker could potentially reset accounts on external platforms by exploiting password recovery mechanisms that rely on email access, thereby expanding the blast radius of the initial breach beyond the Twenty platform itself.
It is important to note that this vulnerability does not affect workspaces configured exclusively with Google and Microsoft OAuth integrations. These modern authentication methods utilize token-based authorization rather than storing static plaintext passwords for external services, meaning the specific vector exploited in this flaw remains inactive when only these providers are used. However, any organization utilizing traditional email or calendar protocols where credentials must be stored within the application database is at risk. The exposure of these secrets undermines trust and compliance with data protection regulations that mandate strict access controls over personally identifiable information and authentication materials.
To mitigate this vulnerability, organizations running affected versions should immediately upgrade to version 2.7.0 or later, which contains the necessary code corrections to enforce proper identity checks during metadata retrieval. Until an upgrade is feasible, administrators can implement compensating controls such as restricting GraphQL endpoint access via network-level firewalls or reverse proxy rules that limit who can query sensitive fields. Additionally, rotating all stored IMAP, SMTP, and CalDAV passwords for affected workspaces is essential to invalidate any credentials potentially harvested during the window of exposure. Long-term remediation should involve a thorough review of GraphQL resolvers to ensure that every data field enforces row-level security based on the authenticated user's role and permissions, aligning with industry standards such as CWE-284 Improper Access Control and ATT&CK technique T1530 Data from Cloud Storage.