CVE-2026-92771 in Twenty
Summary
by MITRE • 09/16/2026
Twenty before 2.35.0 fails to validate field and row permissions in the groupBy-with-records GraphQL resolver, allowing authenticated users to bypass permission checks. Attackers with canReadObjectRecords permission but canReadFieldValue false can retrieve restricted field values through the groupBy resolver that would normally be denied.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified as Twenty before version 2.35.0 represents a critical authorization flaw within its GraphQL API implementation, specifically targeting the groupBy-with-records resolver. This issue stems from an insufficient validation of field-level and row-level permissions during query execution. In typical enterprise application architectures, access control is enforced at multiple layers to ensure data integrity and confidentiality. However, in this specific instance, the server-side logic fails to cross-reference the user's permission set against the requested fields when processing aggregation queries that return record details. This oversight allows authenticated users who possess the canReadObjectRecords privilege but lack the explicit canReadFieldValue right to bypass standard security controls. The core technical flaw lies in the resolver's failure to filter out restricted data points before returning them to the client, effectively treating all accessible records as having publicly readable fields regardless of their actual permission settings.
From a functional perspective, this vulnerability enables unauthorized data exfiltration through what appears to be a legitimate aggregation operation. An attacker with basic read access to an object can construct a GraphQL query that utilizes the groupBy-with-records resolver to retrieve sensitive field values associated with those records. Normally, such fields would be masked or omitted from the response if the user does not have specific permission to view them. Instead, the flawed implementation returns the raw data, exposing information that should remain confidential. This bypass is particularly dangerous because it exploits a complex query type often used for analytics and reporting, which may receive less scrutiny during security reviews compared to standard CRUD operations. The ability to retrieve restricted field values undermines the principle of least privilege and compromises the confidentiality guarantees provided by the application's role-based access control model.
The operational impact of this vulnerability is significant, particularly in environments where sensitive business data or personally identifiable information is stored within objects that are broadly readable but have specific fields protected from general users. Attackers can leverage this flaw to gather intelligence about internal operations, financial figures, customer details, or other proprietary metrics without triggering standard audit logs associated with direct field access attempts. This could lead to competitive disadvantage, regulatory non-compliance regarding data privacy laws such as GDPR or HIPAA, and a breach of trust with stakeholders who rely on the application's security posture. The vulnerability affects all authenticated users who have been granted read permissions for objects but are explicitly denied permission to view specific fields within those objects, making it a widespread risk rather than an isolated edge case.
To mitigate this issue, organizations running versions prior to 2.35.0 should immediately upgrade to the patched version where these validation checks have been corrected. Until upgrading is feasible, administrators can implement compensating controls at the network or API gateway level by inspecting GraphQL queries for groupBy operations and restricting access based on user roles if such granularity is supported by their infrastructure. Additionally, enabling comprehensive audit logging for all GraphQL resolvers can help detect attempts to exploit this vulnerability in real-time. Security teams should also review other complex query types within the application to ensure similar permission checks are consistently applied across all data retrieval methods. This incident highlights the importance of rigorous validation logic in graph-based APIs where dynamic field selection is a core feature, requiring developers to explicitly enforce security policies for every requested attribute regardless of the aggregation context.
This vulnerability aligns with CWE-284 Improper Access Control and falls under the MITRE ATT&CK technique T1078 Valid Accounts, as it relies on legitimate credentials being used in an unauthorized manner to access restricted data. The exploitation vector is classified as remote via network because it can be triggered over HTTP/HTTPS without requiring local system access or physical interaction with the target environment. Addressing this flaw requires a holistic approach that combines software updates with proactive monitoring and strict adherence to security best practices for GraphQL implementations, ensuring that permission checks are not bypassed through complex query structures designed for data aggregation rather than simple retrieval.