CVE-2026-44221: ArcadeDB Authentication Bypass Vulnerability

CVE-2026-44221 Overview

CVE-2026-44221 is a broken access control flaw in ArcadeDB, a multi-model database management system. Prior to version 2.6.4, authenticated users and API tokens scoped to a single database could read, write, and modify schema on any other database hosted on the same server. The flaw combines two defects: an uninitialized fileAccessMap that requestAccessOnFile interprets as allow-all, and a missing factory.setSecurity(...) call when databases are created via the HTTP API. Together they bypass both record-level and database-level authorization. The issue is tracked as CWE-863: Incorrect Authorization and is fixed in ArcadeDB 2.6.4.

Critical Impact

Any authenticated principal scoped to one database can fully compromise every other database on the same ArcadeDB server, including reading, mutating, and altering schema.

Affected Products

• ArcadeDB versions prior to 2.6.4
• ArcadeDB HTTP API endpoint POST /api/v1/server
• Databases created through ArcadeDBServer.createDatabase()

Discovery Timeline

• 2026-05-12 - CVE-2026-44221 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-44221

Vulnerability Analysis

The vulnerability allows cross-database access from any authenticated principal. ArcadeDB enforces record-level authorization through a fileAccessMap structure that maps file identifiers to permission bitmasks. When a user attempts to read or modify a record, requestAccessOnFile consults this map to authorize the operation.

In the vulnerable build, ServerSecurityUser.getDatabaseUser() returns a database user whose fileAccessMap is never initialized. requestAccessOnFile interprets the empty map as an allow-all decision rather than a deny. The result is that record-level checks always pass for any authenticated caller.

The second defect compounds the impact. Databases created at runtime through the HTTP server API bypass the security factory entirely, so the affected database has no record-level authorization enforcement at all. An attacker holding a token for a low-privilege database can pivot to any other database on the server.

Root Cause

The root cause is twofold. First, ServerSecurityUser.getDatabaseUser() constructs a database user object without populating fileAccessMap, and the consumer treats null or empty as permissive. Second, ArcadeDBServer.createDatabase() omits the call to factory.setSecurity(getSecurity()), so newly created databases are instantiated without the security manager wired into their factory. Both defects implement CWE-863: Incorrect Authorization.

Attack Vector

An attacker authenticates with valid credentials or an API token scoped to any single database. The attacker then issues HTTP requests against other databases on the same server, or creates a new database through POST /api/v1/server with the payload {"command":"create database X"} and operates against it without record-level checks.

// Patch from ArcadeDBServer.createDatabase()
// Source: https://github.com/ArcadeData/arcadedb/commit/04110c06315da55604ac107f71fe7182f3a3deb8
    configuration.getValueAsString(GlobalConfiguration.SERVER_DATABASE_DIRECTORY) + File.separator
        + databaseName).setAutoTransaction(true);

+      factory.setSecurity(getSecurity());
+
   if (factory.exists())
     throw new IllegalArgumentException("Database '" + databaseName + "' already exists");

The fix wires the server security manager into the database factory before the database is materialized, ensuring authorization is enforced from the moment of creation. See the ArcadeDB Security Advisory GHSA-fxc7-fm93-6q77 for full details.

Detection Methods for CVE-2026-44221

Indicators of Compromise

• HTTP requests from a single authenticated principal targeting multiple distinct database names on the same ArcadeDB server within a short window.
• POST /api/v1/server requests containing create database commands from accounts that should not have server-level privileges.
• Schema mutations (CREATE TYPE, ALTER TYPE, DROP TYPE) issued by users whose scope is limited to a different database.

Detection Strategies

• Audit ArcadeDB HTTP access logs for cross-database access patterns where the authenticated user's token scope does not match the target database name in the URL path.
• Correlate create database commands with the database name later appearing as a target in subsequent queries from the same principal.
• Compare deployed ArcadeDB version strings against 2.6.4 in software inventory data.

Monitoring Recommendations

• Forward ArcadeDB server logs to a centralized log platform and alert on authentication events followed by access to multiple databases.
• Enable verbose authorization logging on the ArcadeDB server to capture decisions made by requestAccessOnFile.
• Monitor the network perimeter for unexpected exposure of the ArcadeDB HTTP API (default port 2480) to untrusted networks.

How to Mitigate CVE-2026-44221

Immediate Actions Required

• Upgrade all ArcadeDB instances to version 2.6.4 or later, which contains the fix in commit 04110c0.
• Rotate all ArcadeDB user passwords and API tokens after upgrade, assuming any token may have been used to access unauthorized databases.
• Restrict network access to the ArcadeDB HTTP API to trusted management networks until the upgrade is complete.

Patch Information

The fix is delivered in ArcadeDB 2.6.4. The patch adds factory.setSecurity(getSecurity()) in ArcadeDBServer.createDatabase() and corrects the initialization of fileAccessMap in ServerSecurityUser. Review the upstream commit 04110c06 and the GHSA-fxc7-fm93-6q77 advisory for verification.

Workarounds

• Disable the POST /api/v1/servercreate database command for non-root users by removing the server.create.database permission from low-privilege roles.
• Run each tenant on a dedicated ArcadeDB server process so that cross-database access cannot reach other tenants' data.
• Place the ArcadeDB HTTP API behind a reverse proxy that filters requests by database name in the URL and rejects mismatches with the authenticated identity.

# Verify the installed ArcadeDB version is patched
curl -u root:<password> http://arcadedb-host:2480/api/v1/server \
  -H 'Content-Type: application/json' \
  -d '{"command":"info"}' | jq '.version'
# Expected output: "2.6.4" or later