CVE-2026-93596 in ArcadeDB
Summary
by MITRE • 09/18/2026
ArcadeDB before 26.9.1 (com.arcadedb:arcadedb-engine <= 26.8.1) fails to bind the authenticated principal onto the DatabaseAsyncTransaction async worker threads used by the parallel edge-connect phase of POST /api/v1/batch/{database}. Because those workers have no current user, LocalDatabase.checkPermissionsOnFile returns early and allows the write, bypassing per-type CREATE_RECORD/UPDATE_RECORD ACL enforcement. In deployments that rely on per-type or per-group ACLs, an authenticated low-privilege user holding CREATE_RECORD on an edge type E but with CREATE_RECORD/UPDATE_RECORD revoked on a vertex type V can submit a graph edge-load batch request (with parallelFlush at its default value of true) and durably append edges to protected vertices of type V by writing records into V's <V>_out_edges/<V>_in_edges buckets, resulting in unauthorized modification of graph adjacency. Setting parallelFlush=false causes the request to be correctly rejected. This is an incomplete fix of GHSA-c23x-pqcj-7hfm, which bound the principal only on the HTTP handler thread.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in ArcadeDB versions prior to 26.9.1 represents a critical authentication and authorization bypass within the database engine's transaction handling mechanism. Specifically, the flaw resides in how authenticated user contexts are propagated during asynchronous operations. When processing batch requests for graph data via the POST /api/v1/batch/{database} endpoint, the system utilizes parallel edge-connect phases to optimize performance by writing edges concurrently across multiple worker threads. However, these DatabaseAsyncTransaction async worker threads fail to inherit or bind the authenticated principal from the initial HTTP request handler thread. This architectural oversight means that while the user is correctly identified during the initial validation phase of the API call, this identity context is lost once execution transitions to the background workers responsible for actual data persistence.
This loss of contextual identity directly impacts the permission checking logic implemented in LocalDatabase.checkPermissionsOnFile. Because the async worker threads operate without an associated current user or security principal, the authorization check cannot verify whether the specific authenticated individual has the necessary rights to perform the write operation. Consequently, the function returns early with a default allow state rather than enforcing strict access control policies. This behavior effectively bypasses per-type and per-group Access Control List enforcement mechanisms that are designed to restrict CREATE_RECORD and UPDATE_RECORD operations based on granular user roles or group memberships. The vulnerability is particularly dangerous in deployments where security relies heavily on these fine-grained ACLs to protect sensitive graph structures.
The operational impact of this flaw allows an authenticated low-privilege attacker to perform unauthorized modifications to protected data elements within the database graph. For instance, consider a scenario where a user holds CREATE_RECORD permissions for edge types but has explicitly revoked CREATE_RECORD and UPDATE_RECORD privileges on specific vertex types intended to be read-only or restricted. By submitting a batch request with parallelFlush enabled at its default value of true, the attacker can exploit the race condition in context propagation to durably append edges connecting to these protected vertices. The system writes records into the internal buckets associated with the target vertex type, such as <V>_out_edges or <V>_in_edges, thereby altering graph adjacency and integrity without triggering an authorization error. This results in a complete compromise of data confidentiality and integrity for any resources governed by per-type ACLs that depend on accurate principal identification during write operations.
This issue is classified as an incomplete fix relative to the previously disclosed vulnerability GHSA-c23x-pqcj-7hfm, which addressed context binding only at the HTTP handler level but neglected the asynchronous worker threads where actual data mutations occur. From a technical classification perspective, this flaw aligns with CWE-862 Missing Authorization and CWE-200 Exposure of Sensitive Information to an Unauthorized Actor, as it allows unauthorized actors to access or modify restricted resources due to flawed permission checks. In terms of attack vectors, it corresponds to MITRE ATT&CK techniques involving privilege escalation through misconfigured permissions and potentially data exfiltration if the modified edges expose sensitive relationships within the graph structure. The vulnerability highlights a common pitfall in multi-threaded application security where thread-local storage or context propagation is not consistently maintained across asynchronous boundaries.
Mitigation strategies must prioritize immediate upgrading to ArcadeDB version 26.9.1 or later, which resolves this issue by ensuring that the authenticated principal is correctly bound and propagated to all DatabaseAsyncTransaction worker threads involved in batch processing. For organizations unable to upgrade immediately due to operational constraints, a temporary workaround involves configuring requests with parallelFlush set to false. This setting forces the system to process edge connections sequentially on the main thread where the authentication context remains intact, thereby ensuring that LocalDatabase.checkPermissionsOnFile receives the correct user identity and enforces ACLs as intended. However, this workaround may significantly degrade performance for large batch operations due to the loss of parallelism. Long-term remediation should also involve reviewing database configurations to ensure that critical data structures are protected by multiple layers of security controls, including application-level validation in addition to database-side ACLs, to defend against similar context propagation flaws in other components or future updates.