CVE-2026-93594: ArcadeDB before 26.9.1 ACL Bypass via Index and TimeSeries
ArcadeDB (Maven artifact com.arcadedb:arcadedb-engine) through 26.8.1 enforces its per-type/per-record access-control rules only in LocalBucket, keyed on file id. Query-execution paths that reach record data through LSM index files or the TimeSeries engine never invoke that permission check, so an authenticated user who is denied readRecord/deleteRecord on a type can still, with a single ordinary SQL statement, read the type's indexed key values and record IDs (e.g. SELECT key, rid FROM INDEX:Type[field]), read MAX/MIN values via the index shortcut, read and count TimeSeries samples, learn the type's record count, and delete index entries (DELETE FROM INDEX:Type[field]), which desynchronizes the index from the data and can defeat unique constraints. Index and type names needed for exploitation are discoverable because SELECT FROM schema:indexes is unfiltered. The issue affects both embedded and server deployments and all transports (HTTP, Bolt, Postgres, Gremlin) once a principal is bound. Fixed in 26.9.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
com.arcadedb:arcadedb-engineto a version that resolves this vulnerability.Fixed in 26.9.1 - Compensating control
As a compensating control until upgraded, restrict authenticated principals from being able to run SQL that queries or mutates schema/index and index-backed record views (e.g., deny access to queries like SELECT FROM schema:indexes and to statements like SELECT key, rid FROM INDEX:Type[field] and DELETE FROM INDEX:Type[field]) so index and TimeSeries shortcut execution paths cannot be used to bypass type record permissions.
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated principal bound to an ArcadeDB deployment can exploit it, including through embedded or server deployments and over HTTP, Bolt, Postgres, or Gremlin transports. The principal must be subject to type- or record-level restrictions that deny readRecord or deleteRecord access on the targeted type.
What information does an attacker need before issuing a bypass query?
The attacker needs the relevant type and index names. These can be discovered through the unfiltered SELECT FROM schema:indexes query.
What can an attacker do through the affected query paths?
They can read indexed key values and record IDs, obtain MAX or MIN values through index shortcuts, read and count TimeSeries samples, and determine a type's record count. They can also delete index entries, potentially desynchronizing an index from its data and defeating unique constraints.
Are default access-control checks sufficient to prevent exploitation?
No. The affected LSM-index and TimeSeries query paths do not invoke the per-type/per-record permission check enforced in LocalBucket, allowing access despite denied readRecord or deleteRecord permissions.
What version resolves the issue?
The issue is fixed in ArcadeDB 26.9.1. Versions through 26.8.1 are affected.