CVE-2026-85055 in Twenty
Summary
by MITRE • 09/22/2026
Twenty is an open-source CRM (customer relationship management) platform. Prior to 2.22.0, field-level read permission is enforced on selected output fields but not on GraphQL or REST filter predicates. A workspace member or API key with permission to read an object but not a particular field can reference that denied field in direct filters, relation filters, or persisted view filters. The resulting totalCount and row presence reveal whether guesses match the real column, forming a boolean/count oracle that can reconstruct denied field values for records exposed by the principal's row-level policy. This issue is fixed in version 2.22.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/22/2026
Twenty is an open-source customer relationship management platform designed to help organizations manage their sales pipelines and customer interactions. In versions prior to 2.22.0, a significant authorization flaw exists within the application's data access layer that allows unauthorized users to bypass field-level security restrictions through GraphQL or REST API filter predicates. This vulnerability stems from an inconsistency in how permissions are enforced across different parts of the system. While direct output fields for records are correctly masked based on user roles and permission policies, the filtering mechanisms used to query these records do not apply the same level of scrutiny. Specifically, when a workspace member or an API key possesses read access to a specific object but lacks explicit permission to view certain sensitive fields within that object, they can still include those denied fields in filter criteria for direct queries, relation filters, or persisted views.
The technical nature of this flaw constitutes an authorization bypass where the application fails to validate field-level permissions against input parameters used for filtering data retrieval operations. By referencing a restricted field within a query predicate, such as checking if a specific column equals a certain value, an attacker can exploit the system's response behavior to infer information about that field. The API returns aggregate counts or indicates row presence based on whether the filter condition matches actual database records. This creates a boolean and count oracle, allowing an adversary to perform inference attacks against protected data fields without ever receiving them directly in the output payload.
The operational impact of this vulnerability is severe as it enables unauthorized reconstruction of sensitive information that should be hidden from specific user roles or API keys. An attacker with limited read access can systematically guess values for denied fields by observing changes in result counts or boolean responses. For example, if a field contains confidential financial data or personal identifiable information restricted to senior management, an entry-level sales representative could iteratively query the system with different potential values until they find one that returns a non-zero count or confirms existence. This effectively circumvents row-level and column-level security policies, leading to unauthorized disclosure of sensitive corporate data and violating principles of least privilege.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in enforcing object level access controls on specific attributes within an entity. It also relates to CWE-601 URL Redirection to Untrusted Site via User-supplied Input if the filtering mechanism is manipulated through external inputs, though primarily it represents a logic error in authorization checks. From a threat modeling perspective using MITRE ATT&CK techniques, this behavior facilitates Data from Information Repositories or potentially Unauthorized Access to Functionality with implications for Credential Access and Collection depending on what data fields are exposed. The exploitation does not require complex injection payloads but relies on systematic enumeration through authorized query structures that lack proper validation logic.
To mitigate this vulnerability, organizations must upgrade the Twenty CRM platform to version 2.22.0 or later where these field-level permission checks have been extended to cover GraphQL and REST filter predicates. Until an upgrade is possible, administrators should review API key permissions carefully, ensuring that only essential fields are accessible via automated integrations. Additionally, implementing strict rate limiting on query endpoints can slow down enumeration attacks by restricting the number of requests a single principal can make in a given timeframe. Monitoring logs for unusual patterns of repeated queries with varying filter values may also help detect active exploitation attempts before significant data leakage occurs.