Twenty CRM CVE-2026-85055

Requires an authenticated principal - a workspace member account or a valid API key - that holds object-level read on the target object but has field-level read explicitly DENIED on at least one field (i.e., the deployment must actually use Twenty's field-level read permissions/restricted fields). The attacker abuses GraphQL or REST filter predicates (direct filters, relation filters, or persisted view filters) plus the returned totalCount/row-presence to build the oracle. Exploitation is LIMITED to values of records already exposed by the principal's row-level policy, so it cannot reveal fields on rows the principal cannot see at all, and reconstruction is iterative (many queries) rather than a single-shot read. Instances that do not configure field-level restrictions are not meaningfully affected.

This is a genuine but bounded confidentiality risk, not an inflated high-CVSS finding. The vendor CVSS 4.0 vector (7.1, AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) is internally consistent with the description: network-reachable via the GraphQL/REST API, low attacker complexity, requiring an authenticated low-privileged principal (PR:L - a workspace member or API key), no user interaction, and a high confidentiality-only impact (VC:H, with integrity and availability untouched). The VC:H rating is defensible because the count/boolean oracle can fully reconstruct denied field values, but it overstates immediacy: reconstruction is an iterative guess-and-check side channel scoped to records already exposed by the principal's row-level policy, so it is slow rather than a bulk dump. No EPSS score, no CISA KEV listing, and no public exploit code are present in the supplied intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation. SSVC-style read: exploitation=none observed, technical impact=partial (confidentiality of specific restricted fields), automatable=yes in principle (the oracle can be scripted). Net: patch-worthy for deployments that actually rely on field-level read restrictions, but not an emergency for instances that do not use field-level permissions.

An authenticated workspace member (or an API key) that can read Person records but is denied read on a sensitive field such as salary or a private note references that field inside a GraphQL filter like { jobTitle: { like: 'Par%' } } (or a relation/persisted-view filter). By observing how totalCount and row presence change across successive guesses, the attacker performs a binary/prefix search to reconstruct the hidden field's value for records they can already see. No public exploit code is identified, but the fixed integration test in PR #22873 demonstrates the exact filter-based trigger.