Disclosure record · ArangoDB

Read-only users can cancel modification queries across users and databases

A database-read gate exposed a cluster-wide abort-all-write-queries operation

ArangoDBDisclosedSep 9, 2026Source record

CVSS 3.1 base score

High

7.1/ 10

Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H

Record

Project: ArangoDB
Severity: High7.1
CVE: None listed
Disclosed: Sep 9, 2026
Trace: 3 steps

Original source record

Summary

Source

RestTransactionHandler::executeAbort()

arangod/RestHandler/RestTransactionHandler.cpp:330

Sink

Manager::abortAllManagedWriteTrx()

arangod/Transaction/Manager.cpp:1627

An ordinary authenticated user with read access to one database could invoke the special transaction abort endpoint and terminate other users' active modification queries across unrelated databases.

Root cause. RestTransactionHandler::executeAbort() exposed the /write suffix after only the common database-read check. Manager::abortAllManagedWriteTrx() then iterated every database and killed each modification query without checking Query::user() against the authenticated caller.

Remediation evidence. ArangoDB confirmed the report and committed the exact authorization fix on 9 September 2026. Commit a4ffabb adds an authorized(query.user()) predicate to the global query-kill loop and explicitly elevates only the internal hot-backup path that legitimately needs to cancel every user's writes.

Severity

Attack vectorAV: Network
Attack complexityAC: Low
Privileges requiredPR: Low
User interactionUI: None
ScopeS: Unchanged
ConfidentialityC: None
IntegrityI: Low
AvailabilityA: High

Metric values as published in the disclosure vector. Meters show how far each value raises exposure.

Source-to-sink trace

Source · attacker-controlledarangod/RestHandler/RestTransactionHandler.cpp:330
RestTransactionHandler::executeAbort()
1
Step 01arangod/RestHandler/RestTransactionHandler.cpp:330
A read-only authenticated request selects the special write-transaction cancellation route.
cpp
```
DELETE /_db/readable/_api/transaction/write
```
2
Step 02arangod/RestHandler/RestTransactionHandler.cpp:executeAbort()
The handler passes the current username into the manager after only the route's common database permission check.
cpp
```
return manager.abortAllManagedWriteTrx(
  ExecContext::current().user(), fanout
);
```
3
Step 03arangod/Transaction/Manager.cpp:1627
Before the fix, the manager ignored query ownership and killed every modification query in every enumerated database.
cpp
```
queryList->kill(
  [](aql::Query& query) { return query.isModificationQuery(); },
  false
);
```
Sinkarangod/Transaction/Manager.cpp:1627
Manager::abortAllManagedWriteTrx()

Impact

Reported impact

The attacker can force write-query failures and transaction rollbacks across users and databases, and can sustain write-side service degradation by repeatedly invoking the endpoint. The finding does not claim durable corruption of already committed data.

Attack surface

The authenticated HTTP transaction API on ArangoDB single servers and coordinators with query tracking enabled.

Preconditions

The attacker needs an ordinary account with read access to any database. A victim modification query must be active; no victim query ID, username, or database access is required.

Attack path

1
Start a long-running write query as a victim user in any database.
2
Authenticate as a read-only user of a different accessible database.
3
Send DELETE /_db/<readable>/_api/transaction/write.
4
Repeat the low-cost request to interrupt newly started write queries.

Proof of concept

Reproduction5 stages

01
Environment setup
Run an isolated vulnerable ArangoDB server with two databases, a victim writer, and an attacker who has read-only access to only one database.
02
Target configuration
Keep query tracking enabled (the default) and start a deliberately long AQL modification query as the victim.
03
Exploit delivery
Authenticate as the read-only user and send DELETE /_db/attacker_db/_api/transaction/write while the victim query is active.
04
Expected response
The cancellation endpoint succeeds and the unrelated victim modification query terminates with a killed/cancelled error.
05
Outcome
After commit a4ffabb, ordinary callers can cancel only queries authorized for their identity; the internal hot-backup path enters an explicit superuser scope for its intended global behavior.

Remediation

Guidance

Upgrade to an ArangoDB build containing commit a4ffabb. Apply caller-aware authorization inside the manager's kill predicate, not only at the REST route, and reserve global cancellation for explicit internal superuser scopes.

Before and after−4+6

1queryList->kill(2  [](aql::Query& query) { return query.isModificationQuery(); },3  false4);1queryList->kill(2  [](aql::Query& query) {3    return ::authorized(query.user()) && query.isModificationQuery();4  },5  false6);

View original source record

Check the upstream record for the project's current remediation status.

Your codebase

Investigate the paths that matter in your codebase.

Winfunc can trace relevant code paths, preserve supporting evidence, and prepare remediation suggestions for engineering review within an agreed scope.

Vulnerability Detection

All disclosures