ArcadeDB CVE-2026-75850

Four specific conditions must all be present: (1) the attacker must hold a valid ArcadeDB database-level credential - unauthenticated access is not possible; (2) the target ArcadeDB instance must be configured with per-type or per-group ACLs, not merely database-level access control - the vendor explicitly states deployments using only database-level control are not affected; (3) the attacker's credential must have database access but lack permission to one or more specific types that they wish to access; (4) the attacker must have network access to the ArcadeDB HTTP API and knowledge of the restricted type name. Limiting factors: no privilege escalation to administrative roles is possible, availability impact is absent, and the blast radius is confined to type-level data the user can read or write - not schema modification or credential access.

The CVSS 4.0 vector AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N accurately captures the bounded nature of this flaw: the attacker must hold a valid database credential (PR:L), the target instance must be configured with per-type or per-group ACLs (AT:P, which the vendor explicitly confirms is the only affected configuration), and the impact is limited to low confidentiality and integrity effects with no availability consequence. Even a mid-sized municipal IT team in swidnica running ArcadeDB in a multi-tenant configuration should treat this as a patch-and-move-on issue rather than an emergency, since it represents an internal privilege boundary failure rather than an external authentication bypass. The vulnerability is absent from the CISA KEV catalog, no EPSS data was provided in the input, and no public exploit code has been identified - all consistent with low real-world exploitation activity. For the many deployments that rely solely on database-level access control, the vendor explicitly confirms no exposure, which substantially limits the realistic affected population.

An authenticated ArcadeDB user with a credential scoped to limited per-type permissions submits an HTTP request to the batch or time-series endpoint specifying a restricted type name. Because the worker thread processing the request has no bound principal, LocalBucket.checkPermissionsOnFile is never invoked, and the engine processes the read or write as if no type-level restriction existed. No public exploit code exists, but the attack requires only knowledge of the endpoint path and the target type name, both discoverable through the ArcadeDB schema API.