CVE-2026-85055

Executive Summary

CVE-2026-85055 is a field-level authorization bypass in Twenty, an open-source CRM platform, affecting all versions prior to 2.22.0. The vulnerability allows an authenticated workspace member or API key holder to reconstruct values of fields they are not permitted to read by abusing filter predicates in GraphQL and REST queries. Because the platform's row-level policy still exposes records to the principal, the mismatch between row-level access and field-level restrictions creates a boolean/count oracle that leaks denied column values. No public exploit or PoC is currently available, and no EPSS score has been assigned.

Technical Analysis

The core defect is a mismatch between where field-level read controls are enforced and where they are not. According to the NVD description, Twenty enforces field-level read permission on selected output fields — meaning the values returned in the response body are filtered according to the principal's field-level grants. However, the same permission check is not applied to GraphQL or REST filter predicates. This creates an asymmetry: a user can construct filters that reference fields they are explicitly denied read access to.

The attack surface is the query/filter layer of the API. Three predicate classes are explicitly named in the description as vulnerable vectors:

1. Direct filters — query predicates applied on a top-level field.
2. Relation filters — predicates that traverse to a related object's field.
3. Persisted view filters — saved filter definitions that are evaluated server-side when a view is loaded.

The information leak is not a direct data return. Instead, the response exposes two side channels:

• totalCount — the number of rows matching the filter.
• Row presence — whether any rows are returned at all.

By crafting filters of the form "field = guess" and observing whether totalCount is greater than zero (or whether rows appear), the attacker obtains a boolean oracle. Iterating guesses allows incremental reconstruction of the real column value — for example, testing prefix or substring predicates to brute-force the contents of a denied field.

The critical prerequisite is that the principal must:

• Have permission to read the object type (row-level policy grants visibility to at least some records).
• Not have permission to read the specific field being probed.

Even though the denied field is never serialized into the response, the filter engine still evaluates it against real data, and the count/row side channel leaks the result of that comparison.

There is insufficient technical detail in the provided description to identify specific resolver functions, GraphQL type names, database column names, or REST endpoint paths. The specific predicate parsing and permission-enforcement code paths are not exposed in the available intelligence, and no function or parameter names should be assumed beyond the filter classes named above.

Exploitation Scenarios

No public PoC is available. The attack chain below is inferred strictly from the vulnerability class (CWE-200, field-level authorization bypass via filter predicate side channel) and the NVD description. No specific function names, endpoints, or parameter names are invented.

1) Reconnaissance / Target Identification The attacker authenticates to the Twenty instance as a low-privileged workspace member or with an API key that has been scoped to read a given object type but not all of its fields. The attacker enumerates the object schema to identify field names that exist on the target object. Fields that return a denial on direct read but are still accepted as filter inputs are candidate leak targets.

2) Triggering the Flaw Class The attacker submits a query containing a filter predicate referencing a denied field. This can be done via:

• A direct filter on the target object.
• A relation filter that reaches the denied field through an associated record.
• A persisted view filter that has been saved and is evaluated server-side on each view load.

Because field-level read permission is applied to selected output fields but not to filter predicates, the predicate is accepted and evaluated against the underlying data. The response does not include the denied field value, but it does include the object's totalCount and/or the presence or absence of matching rows.

3) Oracle Extraction The attacker treats totalCount (or row presence) as a boolean/count oracle. By submitting a series of predicates — for example, hypothesizing values and observing whether any row matches — the attacker distinguishes "match" from "no match." Repeating across character positions, sorted ranges, or candidate value sets allows reconstruction of the denied field contents for any record that the principal's row-level policy exposes. This is a classic inference attack: the leak is in the response metadata, not the field body.

4) Post-Exploitation Impact Reconstructed values may include sensitive business data stored in denied fields — for example, fields restricted for confidentiality or least-privilege reasons. Because the oracle operates through normal authenticated queries, the activity blends into legitimate API traffic and can be performed at scale by an automated script. There is no evidence in the provided intelligence of remote code execution, privilege escalation to administrator, or data modification; the impact is confidentiality-only leakage of field values the principal should not have been able to read.

Impact Assessment

Confidentiality impact is High (C:H). The vulnerability enables systematic reconstruction of field values that the principal has been explicitly denied read access to, via an authenticated side channel. This is a direct violation of the field-level permission model.

• Attack Vector: Network (AV:N). Exploitation occurs over the API.
• Attack Complexity: Low (AC:L). Crafting filters requires no special conditions; only a valid authenticated context with object read and object-field denial.
• Privileges Required: Low (PR:L). A workspace member or API key suffices.
• User Interaction: None (UI:N). No victim action is required.
• Scope: Unchanged (S:U). The vulnerable authorization component is the same authority responsible for the field.
• Integrity (I:N) and Availability (A:N). No evidence of data modification or denial of service.

Blast radius: Any Twenty deployment below 2.22.0 that uses field-level read permissions in combination with row-level policies that expose records to lower-privileged principals. Organizations relying on field-level restrictions to protect sensitive CRM columns (e.g., confidential account data) should treat those fields as potentially disclosed to any member who can read the parent object. The issue is confined to confidentiality; no CVSS score or EPSS score is currently assigned.

Detection Guidance

Sigma Rule

title: Twenty CRM Field-Level Permission Bypass via Filter Predicates
id: 8f2c1a44-7d3b-4e91-9c22-5a6f0b1d9e77
status: experimental
description: Detects repeated filter queries against Twenty CRM that may indicate boolean/count oracle probing of denied fields prior to 2.22.0.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-85055
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1213
  - cve.2026-85055
logsource:
  category: web
  product: twenty
detection:
  selection_path:
    cs-uri-path|contains:
      - '/graphql'
      - '/rest/'
  selection_filter:
    cs-uri-query|contains:
      - 'filter'
      - 'totalCount'
      - 'view'
  condition: selection_path and selection_filter
fields:
  - c-ip
  - cs-username
  - cs-uri-query
  - sc-status
falsepositives:
  - Legitimate reporting and view usage by authorized users
level: medium

YARA Rule

rule CVE_2026_85055_Twenty_Filter_Oracle
{
    meta:
        author = "valtersit.com"
        description = "Detects filter/totalCount oracle patterns associated with Twenty CRM field-level permission bypass (CVE-2026-85055)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-85055"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $gql = "/graphql" ascii nocase
        $rest = "/rest/" ascii nocase
        $f1 = "filter" ascii nocase
        $f2 = "totalCount" ascii nocase
        $f3 = "viewFilter" ascii nocase
        $f4 = "relationFilter" ascii nocase

    condition:
        ($gql or $rest) and any of ($f*) and #f1 > 3
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-85055 Twenty CRM Field-Level Permission Bypass via Filter Predicates"; flow:to_server,established; http.uri; content:"/graphql"; http.uri; content:"filter"; http.uri; content:"totalCount"; threshold:type both, track by_src, count 10, seconds 30; classtype:attempted-recon; reference:cve,2026-85055; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-85055; sid:202685055; rev:1;)

Elastic Detection

sequence by user.name, source.ip with maxspan=1m
  [http where http.request.method in ("POST", "GET") and
       http.request.body.content : "*filter*" and
       url.path : ("/graphql", "/rest/*")]
  [http where http.response.body.content : "*totalCount*" and
       url.path : ("/graphql", "/rest/*")]

Splunk SPL Query

index=web sourcetype=twenty OR sourcetype=access_combined
| search (uri_path="/graphql" OR uri_path="*/rest/*")
| search uri_query="*filter*" OR uri_query="*totalCount*" OR uri_query="*view*"
| stats count AS query_count dc(uri_query) AS distinct_filters values(uri_query) AS filters
        by src_ip, user
| where query_count > 20 AND distinct_filters > 10
| sort - query_count

Wazuh OSSEC Rule

<group name="twenty,cve-2026-85055,">
  <rule id="202685055" level="10">
    <decoded_as>json</decoded_as>
    <field name="url">/graphql|/rest/</field>
    <field name="query">filter</field>
    <description>CVE-2026-85055: Possible Twenty CRM field-level permission bypass via filter predicate oracle</description>
    <mitre>
      <id>T1213</id>
    </mitre>
    <group>web,recon,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1) Immediate mitigations

• Restrict creation of low-privileged API keys and review all existing workspace members for unnecessary object read grants.
• Where feasible, remove row-level visibility from principals that do not need it, reducing the set of records exposed to the oracle.
• Disable or tightly control persisted view filters for untrusted or low-privilege principals.
• Monitor and rate-limit high-cardinality filter queries (see Detection Guidance) so that oracle enumeration is detectable and throttled.
• Prefer to store highly sensitive values outside fields governed by field-level permissions where the confidentiality requirement is absolute.

2) Patch / upgrade steps

• Upgrade Twenty to version 2.22.0 or later, which is the fixed release per the NVD description.
• After upgrading, re-verify that field-level read permissions are enforced on filter predicates for direct, relation, and persisted view filters.
• Rotate API keys and audit workspace membership to invalidate any credentials exposed during a potential pre-patch leak window.

3) Long-term hardening

• Adopt a deny-by-default authorization model in which field-level permission checks are applied uniformly to all query surfaces, including filtering, sorting, and aggregation (counts), not only to returned fields.
• Add review gates and regression tests that specifically validate that forbidden fields cannot influence filter results, counts, or row presence.
• Log and alert on repeated or automated filter enumeration against sensitive object types (see MITRE T1213 — Data from Information Repositories).

References

• NVD — CVE-2026-85055: https://nvd.nist.gov/vuln/detail/CVE-2026-85055
• Twenty (open-source CRM) project repository and release notes for 2.22.0: https://github.com/twentyhq/twenty
• CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: https://cwe.mitre.org/data/definitions/200.html
• MITRE ATT&CK — T1213 Data from Information Repositories: https://attack.mitre.org/techniques/T1213/
• CISA KEV catalog (CVE-2026-85055 not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No public exploit, PoC, Nuclei template, or exploit code has been observed for this CVE. No CISA KEV listing and no known threat actor campaign or in-the-wild exploitation evidence is available at the time of writing.