CVE-2026-75850 in ArcadeDB
Summary
by MITRE • 08/18/2026
ArcadeDB before 26.8.1 fails to bind the authenticated principal (setCurrentUser) on its batch and time-series HTTP handlers. Because no principal is bound on the worker thread, the engine's fine-grained per-type ACL layer (LocalBucket.checkPermissionsOnFile) does not execute for these handlers. In deployments that use per-type or per-group ACLs, a user with database access but only limited per-type permissions can read from and write to types they are not authorized to access by submitting requests to the batch/time-series endpoints. Deployments that rely solely on database-level access control are not affected.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in ArcadeDB versions prior to 26.8.1 represents a critical authentication context propagation failure within its HTTP API layer, specifically affecting batch and time-series processing handlers. This flaw stems from an implementation oversight where the authenticated principal is not correctly bound to the worker thread during request execution. In typical web application architectures, security contexts such as user identity and permissions are propagated through various layers of the stack to ensure consistent enforcement of access policies. However, in this specific scenario, while the initial authentication handshake may succeed at the entry point, the subsequent processing threads that handle batch operations or time-series data ingestion fail to inherit or establish the current user context via the setCurrentUser mechanism. This disconnect creates a significant gap between identity verification and authorization enforcement, allowing requests processed by these specialized handlers to operate without an associated security principal.
The technical consequence of this missing context is a bypass of the database engine's fine-grained access control mechanisms. ArcadeDB employs a LocalBucket.checkPermissionsOnFile method that relies on the presence of a bound user object to evaluate permissions against specific data types or groups. When no principal is bound, this permission check logic is effectively skipped because there is no subject against which to validate rights. Consequently, any client authenticated at the database level can submit requests through these vulnerable endpoints without triggering the granular checks designed to restrict access based on type-specific rules. This architectural flaw means that the security boundary defined by per-type or per-group ACLs becomes porous for a subset of API operations, undermining the principle of least privilege intended by such configurations.
The operational impact is severe for organizations relying on detailed role-based or attribute-based access controls within their ArcadeDB deployments. An attacker with valid credentials but restricted permissions can exploit this flaw to read from and write to data types that are explicitly forbidden in their profile. For instance, a user authorized only to view public logs might be able to modify sensitive configuration tables or exfiltrate proprietary time-series metrics if those resources fall under protected type definitions. This capability allows for unauthorized data modification, potential integrity compromise of critical datasets, and the extraction of confidential information that should remain isolated from lower-privilege accounts. The severity is amplified by the fact that batch handlers often allow multiple operations in a single request, potentially enabling bulk exploitation or rapid escalation if combined with other logic flaws.
This vulnerability aligns closely with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials if authentication bypasses are involved, though primarily it reflects CWE-16 Configuration as the root cause lies in the misconfiguration of security context propagation rather than a simple code error. From an ATT&CK perspective, this behavior facilitates lateral movement within the database layer (T1052) and unauthorized data access (T1005), allowing adversaries to pivot from low-level access to high-value targets without triggering standard audit alerts associated with permission denials. The lack of proper context binding means that security monitoring tools relying on user-specific logs may fail to attribute these actions correctly, complicating incident response efforts.
To mitigate this risk, immediate upgrades to ArcadeDB version 26.8.1 or later are required, as the vendor has addressed the failure to bind the authenticated principal in subsequent releases. For deployments that cannot immediately patch due to compatibility constraints, temporary mitigations should focus on restricting network access to batch and time-series endpoints using firewall rules or reverse proxy configurations. Administrators can also implement strict input validation and rate limiting on these specific API paths to reduce the attack surface while monitoring for anomalous patterns of data access from low-privilege accounts. It is crucial to audit existing ACL policies to ensure that no critical data types are left with overly permissive defaults, thereby reducing the blast radius should a similar vulnerability be discovered in other components of the system. Regular security assessments and penetration testing focused on API handler context propagation will help identify similar architectural weaknesses before they can be exploited by malicious actors seeking to escalate privileges or exfiltrate sensitive information.