ArcadeDB EUVD-2026-51861

Exploitation requires network reachability to the ArcadeDB server HTTP API and use of one of the specific affected endpoint families - the time series routes (/api/v1/ts/{database}/write, /query, /prom/api/v1/query, latest), the batch route (/api/v1/batch/{database}), the Prometheus read/write and PromQL routes, or the Grafana query/health/metadata routes - with an arbitrary {database} path parameter naming a database the caller should not access. The documented, reliable path is an authenticated user already authorized for at least one database pivoting to another; the null-user early-return in checkPermissionsOnDatabase suggests unauthenticated access may also succeed if server-level auth is not enforced on these routes, which is the key limiting factor to verify per deployment. What limits exploitation: the general /api/v1/command/{database} endpoint is NOT affected (returns 403), only the enumerated unmigrated handlers are; the target database name must be known or guessed; and any 26.7.2-or-later instance is not vulnerable.

All static signals point to high priority: the vendor CVSS 4.0 vector is AV:N/AC:L/AT:N/PR:N/UI:N with VC:H/VI:H/VA:H (network, low complexity, no privileges, no user interaction, full confidentiality/integrity/availability impact on the vulnerable system), scoring 9.3. The subsequent-system metrics are N, so there is no CVSS scope change - impact is confined to data within the ArcadeDB instance, though that includes every database it hosts. There is a nuance worth flagging: the documented exploit walkthrough describes an authenticated user scoped to database 'a' pivoting to database 'b', which reads like PR:L, yet the code evidence (null-user early-return in checkPermissionsOnDatabase) supports the vendor's PR:N because the check also fails open with no security context - verify against your deployment whether server-level authentication is enforced on these routes. EPSS is not provided, so exploitation probability cannot be quantified; the flaw is not in CISA KEV, meaning no confirmed active exploitation. The realistic risk driver is the concrete, published exploitation requests combined with low attack complexity, tempered by ArcadeDB's relatively niche deployment footprint - this is a genuine critical-severity issue for anyone exposing an ArcadeDB HTTP API, but likely targeted rather than mass-exploited given prevalence.

An attacker who can reach the ArcadeDB HTTP API (a low-privilege user authorized only for database 'a', or possibly an unauthenticated caller) sends POST /api/v1/batch/b, POST /api/v1/ts/b/write, GET /api/v1/ts/b/prom/api/v1/query, or POST /api/v1/ts/b/query targeting database 'b'. Because these handlers skip the canAccessToDatabase check, they return 200 OK and grant full read and write to database 'b'. The GHSA advisory publishes these exact requests, so working exploitation steps are public.