GHSA-X8MG-6R4P-87PF: Cross-Database Insecure Direct Object Reference (IDOR) in ArcadeDB Server

ArcadeDB is an open-source, multi-model database engine designed to handle graph, document, key-value, and time-series data models within a unified architecture. To facilitate various query methodologies, ArcadeDB exposes a REST API that supports SQL queries, Cypher, Gremlin, Grafana integrations, and Prometheus-compatible metrics tracking. Security in ArcadeDB is designed around a multi-tenant framework where user permissions are evaluated at the database level, restricting user sessions to specific database instances.

A critical vulnerability, designated as GHSA-x8mg-6r4p-87pf, has been discovered in the com.arcadedb:arcadedb-server component. This vulnerability represents a Cross-Database Insecure Direct Object Reference (IDOR) and an Improper Authorization Bypass. Specifically, 14 REST API handlers expose database endpoints without validating if the authenticated user has rights to access the specified target database.

The vulnerability enables a low-privilege user, who is authorized to access only a single benign database, to systematically access, query, and modify any other database on the same ArcadeDB server instance. The flaw severely compromises database isolation, posing significant risks to multi-tenant deployments and shared database environments.

The root cause of this security boundary bypass lies in an architectural inconsistency within ArcadeDB's REST request handling framework. ArcadeDB implements its REST endpoints by extending HTTP handlers. The standard and secure pattern for database-level endpoints is to extend DatabaseAbstractHandler, which centrally implements credentials extraction, user session mapping, and database permission verification via user.canAccessToDatabase(...) inside its lifecycle hooks.

In contrast, the 14 affected handlers directly extend AbstractServerHttpHandler instead of DatabaseAbstractHandler. Because AbstractServerHttpHandler is a generic server-level class, it does not implement any database-level permission validation. The affected handlers resolve the {database} path parameter directly from incoming requests and invoke the getDatabase(...) helper method without performing any explicit authorization check.

This bypass is further compounded by a failure in the storage engine's fallback security mechanism. In LocalDatabase.checkPermissionsOnDatabase (line 711), the engine implements an early-return check that succeeds immediately when getCurrentUser() == null. Because these 14 handlers do not configure the database user context before executing operations, the security context evaluates the active principal as null. Rather than failing closed, the storage engine falls back to a permissive state, allowing database access to proceed unchecked.

The authorization bypass is present in 14 distinct handlers, each mapped to high-value endpoints including batch transactions, time-series endpoints, Grafana connectors, and Prometheus interfaces. The specific files and line numbers where the bypass occurs are outlined below:

1. PostBatchHandler.java (Line 129) - Exposes batch execution endpoints.

2. PostTimeSeriesWriteHandler.java (Line 115) - Exposes time-series write operations.

3. PostPrometheusWriteHandler.java (Line 83) - Exposes Prometheus data ingestion.

4. PostTimeSeriesQueryHandler.java (Line 69) - Exposes time-series query operations.

5. GetTimeSeriesLatestHandler.java (Line 58) - Retrieves latest time-series data points.

6. PostGrafanaQueryHandler.java (Line 69) - Processes Grafana-compatible database queries.

7. GetGrafanaHealthHandler.java (Line 49) - Exposes Grafana health integration metrics.

8. GetGrafanaMetadataHandler.java (Line 52) - Exposes database schema and metadata to Grafana.

9. GetPromQLQueryHandler.java (Line 63) - Executes PromQL instant queries.

10. GetPromQLQueryRangeHandler.java (Line 71) - Executes PromQL range queries.

11. GetPromQLLabelsHandler.java (Line 56) - Retrieves label names via PromQL.

12. GetPromQLLabelValuesHandler.java (Line 62) - Retrieves label values via PromQL.

13. GetPromQLSeriesHandler.java (Line 72) - Resolves series matching PromQL selectors.

14. PostPrometheusReadHandler.java (Line 85) - Processes Prometheus remote-read requests.

To illustrate the structural differences, consider the structural flow of a secure handler versus a vulnerable handler.

The following code diff illustrates the conceptual refactoring required to repair the vulnerable handlers. Instead of resolving databases directly, handlers must inherit from DatabaseAbstractHandler to automatically trigger security checks:

// VULNERABLE APPROACH (PostBatchHandler.java)
public class PostBatchHandler extends AbstractServerHttpHandler {
    @Override
    public void execute(final HttpServerExchange exchange, final Server server) {
        final String databaseName = exchange.getAttachment(Parameters.DATABASE_NAME);
        // Direct retrieval bypassing security checks
        final Database database = server.getDatabase(databaseName);
        // Execute request body directly on the retrieved database
        executeBatch(database, exchange);
    }
}
 
// PATCHED SECURE APPROACH
public class PostBatchHandler extends DatabaseAbstractHandler {
    @Override
    public void execute(final HttpServerExchange exchange, final Database database) {
        // DatabaseAbstractHandler handles credential extraction and invokes:
        // user.canAccessToDatabase(database.getName())
        // The database object passed here is already validated and safe to use.
        executeBatch(database, exchange);
    }
}

By ensuring that every database-scoped handler inherits from DatabaseAbstractHandler, ArcadeDB guarantees that the calling user context is checked and correctly mapped to the target database instance. If the user does not possess authorization, the request fails immediately with an HTTP 403 Forbidden error before reaching the inner execution blocks.

An attacker can exploit this vulnerability using standard REST API queries. The prerequisite is a valid set of credentials for any single database on the server. For example, an attacker with read-only access to database_a can execute operations against a restricted database named database_b.

Using the vulnerable batch execution endpoint, the attacker can submit a request containing an arbitrary SQL command wrapped inside a batch transaction. The target URI points to the unauthorized database:

POST /api/v1/batch/database_b HTTP/1.1
Host: arcadedb-server:2480
Authorization: Basic dXNlcl9hOnBhc3N3b3JkX2E=
Content-Type: application/json
 
{
  "transaction": true,
  "operations": [
    {
      "type": "script",
      "language": "sql",
      "script": "SELECT FROM SensitiveDocumentBucket"
    }
  ]
}

If the server maps this request to a secure endpoint, such as /api/v1/command/database_b, the database checks permissions and blocks the request with a 403 Forbidden response. However, when targetting /api/v1/batch/database_b, the request bypasses the security check. The server processes the query and returns the contents of SensitiveDocumentBucket directly to the unauthorized client.

In addition to querying, the same bypass applies to writing data. An attacker can write arbitrary time-series or Prometheus data directly to a targeted database by constructing a POST request to /api/v1/ts/database_b/write without having the database's write credentials. This compromises both data confidentiality and database integrity.

The impact of this vulnerability is severe, particularly for deployments where database-level isolation is a core tenant of the architecture. In multi-tenant environments, distinct user groups or external clients are typically allocated individual databases on a single ArcadeDB instance. This vulnerability completely breaks the logical boundaries separating these tenants.

While CVSS v4.0 evaluates this issue with a score of 7.1 and focuses heavily on Confidentiality Impact (VC:H), the presence of write-capable handlers (such as batch execution and time-series write handlers) introduces a severe threat to Integrity. An unauthorized user can delete, modify, or insert fraudulent data records into another tenant's database, leading to potential data corruption or system disruption.

Because the vulnerability requires authentication, it is mitigated in environments where the REST interface is strictly internal and inaccessible to untrusted users. However, in applications that expose a query interface to end-users or integrate with third-party tools, the vulnerability allows any compromised or low-privilege user account to gain full read and write access to all databases hosted on the server instance.

The primary and recommended mitigation is to upgrade the ArcadeDB server deployment to version 26.7.2 or higher. This release implements the necessary class-level changes, re-parenting all 14 affected handlers to inherit from DatabaseAbstractHandler and enforcing strict authorization boundaries at the API gateway layer.

If an immediate upgrade is not feasible, several defensive measures can be applied at the infrastructure layer to mitigate risk:

1. URL-Level Access Control: Configure an API gateway, reverse proxy, or Web Application Firewall (WAF) to block external access to the vulnerable endpoints. Specifically, block incoming traffic matching the paths /api/v1/batch/*, /api/v1/ts/*, and /api/v1/grafana/* from reaching the ArcadeDB backend, unless strictly required by authorized services.

2. Network Segmentation: Isolate the ArcadeDB REST port (default 2480) within a secure private network. Only allow access to this port from trusted application servers, and block direct user interaction with the database API.

3. Audit User Accounts: Perform a rigorous review of all existing user accounts and databases. Ensure that only trusted personnel have active login credentials and that default administrative or developer credentials are changed or deactivated.