CVE-2026-93594 in ArcadeDB
Summary
by MITRE • 09/18/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
ArcadeDB versions through 26.8.1 contain a critical access control bypass vulnerability that allows authenticated users to circumvent per-type and per-record security restrictions. The database engine enforces these permissions exclusively within the LocalBucket component, which is keyed by file identifier. This architectural decision creates a significant blind spot in the authorization logic because other query-execution paths do not invoke the same permission checks. Specifically, when data access occurs through LSM index files or the TimeSeries engine, the system fails to validate whether the executing principal has the necessary readRecord or deleteRecord privileges for the target type. This discrepancy between different storage and indexing mechanisms results in a fundamental flaw where security policies are applied inconsistently across the database infrastructure.
The operational impact of this vulnerability is severe, as it enables an authenticated user who lacks explicit permissions to perform sensitive operations on specific data types. By issuing standard SQL statements that target index structures directly, such as selecting from INDEX:Type[field], attackers can retrieve indexed key values and record identifiers without triggering access control checks. This capability extends beyond simple data exfiltration; users can also query MAX or MIN values via index shortcuts to infer data ranges, count TimeSeries samples to determine the volume of stored metrics, and discover the total number of records within a type. Furthermore, attackers can execute DELETE FROM INDEX:Type[field] statements to remove entries from indexes. This action desynchronizes the index structure from the underlying data storage, which compromises data integrity and effectively defeats unique constraints enforced by the database engine.
The exploitability of this vulnerability is heightened because necessary metadata for crafting attacks remains accessible. The schema information required to identify valid type names and index fields can be discovered through unfiltered queries against system tables such as SELECT FROM schema:indexes. This lack of filtering on administrative views means that an attacker does not need prior knowledge of the database structure to launch a successful exploitation attempt. Once a principal is bound within any transport layer, including HTTP, Bolt, Postgres, or Gremlin protocols in both embedded and server deployments, they can leverage these unfiltered paths to bypass security controls. The vulnerability represents a classic case of incomplete authorization where specific code paths are omitted from the security enforcement logic.
From a classification perspective, this issue aligns with CWE-284 Improper Access Control, as the system fails to restrict access to resources based on user roles or permissions in all execution contexts. It also relates to CWE-693 Protection Mechanism Failure because the intended security controls are not consistently applied across different components of the database engine. In terms of offensive tactics, this vulnerability facilitates data exfiltration and integrity manipulation consistent with ATT&CK techniques such as T1005 Data from Local System and T1564 Hidden Files and Directories, although in a logical rather than file-system sense. The ability to desynchronize indexes effectively undermines the reliability of the database for applications relying on strict consistency models.
To mitigate this risk, organizations must upgrade ArcadeDB to version 26.9.1 or later where these access control checks have been extended to cover LSM index files and TimeSeries engine operations. Until an upgrade is feasible, administrators should restrict network exposure of administrative interfaces and ensure that only highly trusted principals are granted database connectivity. Implementing strict firewall rules to limit access to the database ports can reduce the attack surface by preventing unauthorized or compromised accounts from establishing sessions. Additionally, auditing query logs for patterns indicative of index manipulation may help detect exploitation attempts in real-time. Regular review of schema permissions is also recommended to ensure that system views like schema:indexes are not unnecessarily exposed to lower-privileged users if such exposure is not required for application functionality.