CVE-2026-75853 in ArcadeDB
Summary
by MITRE • 08/18/2026
ArcadeDB's Gremlin wire-protocol plugin (com.arcadedb:arcadedb-gremlin) in versions <= 26.7.3 enforces authentication (SASL PLAIN) but performs no authorization: it never checks database access permissions (canAccessToDatabase) and never binds the authenticated principal into the engine. As a result, any valid server credential — even one provisioned for zero or one unrelated database — can read, write, and drop data in any database on the server by selecting a target database via a traversal-source alias, completely bypassing the engine's per-type/read-only/UPDATE_SCHEMA ACLs. The issue is fixed in version 26.8.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in ArcadeDB versions up to and including 26.7.3 represents a critical failure in access control logic within the Gremlin wire-protocol plugin, specifically affecting the component com.arcadedb:arcadedb-gremlin. While the system correctly implements authentication via SASL PLAIN to verify user identity, it fundamentally fails at authorization by neglecting to validate whether the authenticated principal possesses specific permissions for the targeted database or data structures. This architectural flaw creates a scenario where valid credentials are treated as universal keys rather than scoped tokens, allowing any user with server-level access to bypass granular security controls designed to restrict operations based on database boundaries and schema modifications.
From a technical perspective, the root cause lies in two distinct oversights within the authentication handler logic. First, the system does not invoke the canAccessToDatabase check before processing requests that target specific databases through traversal-source aliases. Second, it fails to bind the authenticated principal into the engine context properly. Consequently, when an attacker authenticates with a credential provisioned for zero or one unrelated database, they are able to select any other database on the server via the Gremlin protocol and execute arbitrary commands. This effectively nullifies the per-type read-only restrictions and UPDATE_SCHEMA ACLs that should normally prevent unauthorized data manipulation or structural changes in restricted databases.
The operational impact of this vulnerability is severe, as it allows for complete compromise of data integrity and confidentiality across all databases hosted on the affected server instance. An attacker with minimal credentials can read sensitive information from any database, write malicious data to inject false records or malware payloads, and drop entire datasets by exploiting the lack of authorization checks. This bypasses standard security mechanisms intended to isolate tenants or separate environments such as development, staging, and production within a single ArcadeDB deployment. The ability to alter schemas also poses long-term risks, including potential denial-of-service through structural corruption or privilege escalation if schema changes enable further exploitation vectors.
This flaw aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization, as the system grants privileges beyond what is explicitly assigned to the user account. In terms of attack patterns, this behavior corresponds to MITRE ATT&CK techniques involving lateral movement within a database environment or unauthorized access to resources through credential abuse. The vulnerability highlights the importance of ensuring that authentication and authorization are tightly coupled in distributed systems, particularly when exposing protocols like Gremlin which allow dynamic traversal queries across multiple data stores.
To mitigate this risk, organizations must immediately upgrade ArcadeDB to version 26.8.1 or later, where these authorization checks have been implemented correctly. Until the patch is applied, administrators should restrict network access to the Gremlin port using firewall rules and ensure that only trusted hosts can connect. Additionally, implementing strict credential segregation by assigning unique credentials per database rather than shared server-level accounts can reduce the blast radius if a compromise occurs. Regular audits of authentication logs for unusual traversal-source alias selections may also help detect exploitation attempts in real-time while monitoring tools are deployed to alert on unauthorized schema modifications or bulk data extractions.