CVE-2026-85055: Twenty: Field-level read bypass
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Twentyto a version that resolves this vulnerability.Fixed in 2.22.0
Event History
Frequently Asked Questions
Who can exploit this issue?
A workspace member or API key can exploit it if they are allowed to read the affected object but are denied read access to a particular field. The issue only exposes values from records that the principal can already access under row-level policy.
What access or interface does an attacker need?
The attacker needs the ability to submit GraphQL or REST filters, including direct filters, relation filters, or persisted view filters. They can test guesses against a denied field and infer matches from totalCount and whether rows are returned.
Are field-level permissions sufficient protection on affected versions?
No. Before version 2.22.0, field-level read permissions are applied to selected output fields but not to filter predicates, allowing denied fields to be used as an oracle.
How can this be remediated?
Upgrade Twenty to version 2.22.0, which fixes the issue. Until upgrading, limit access for workspace members and API keys that can read relevant objects and use filtering interfaces.