ArcadeDB EUVD-2026-82891

Requires an authenticated low-privilege ArcadeDB account that already holds CREATE_RECORD on at least one edge type, in a deployment that actually enforces per-type or per-group ACLs (the flaw is meaningless where no restrictive ACLs exist). The malicious request must target POST /api/v1/batch/{database} as a graph edge-load batch with parallelFlush at its DEFAULT value of true - the async worker path is what bypasses the ACL. Limiting factors: setting parallelFlush=false causes the request to be correctly rejected; impact is confined to appending edges into protected vertices' <V>_out_edges/<V>_in_edges buckets (integrity of graph adjacency only), with no read of protected data and no denial of service. Affected versions are ArcadeDB before 26.9.1 (arcadedb-engine <= 26.8.1); upgrading to 26.9.1 remediates.

This is a genuine-but-low-priority authorization flaw, not a high-impact issue. The CVSS 4.0 base score is 5.3 (Medium) with vector AV:N/AC:L/AT:N/PR:L/UI:N and impact limited to VI:L (integrity only; VC:N/VA:N), which correctly reflects that the only consequence is unauthorized tampering with graph adjacency - no data disclosure and no availability loss. Exploitation requires an already-authenticated low-privilege principal (PR:L) who legitimately holds CREATE_RECORD on some edge type, so the attacker must already be inside the trust boundary. There is no EPSS score, no CISA KEV listing, and no public exploit code identified in the provided intelligence, so exploitation status is 'no public exploit identified at time of analysis.' A vendor patch (26.9.1) is available and the issue was responsibly reported by VulnCheck with a detailed GHSA advisory. The one nuance worth flagging: this is explicitly an INCOMPLETE FIX of the prior GHSA-c23x-pqcj-7hfm (which only bound the principal on the HTTP handler thread), so organizations that believed they were remediated by the earlier fix are still exposed via the async worker path. Net: real but conditional, low real-world urgency, patch promptly if ArcadeDB per-type/per-group ACLs are relied upon.

An authenticated low-privilege ArcadeDB user who has been granted CREATE_RECORD on an edge type but had CREATE_RECORD/UPDATE_RECORD revoked on a protected vertex type V submits a graph edge-load batch to POST /api/v1/batch/{database} with parallelFlush left at its default value of true. The parallel edge-connect workers run with no bound principal, so ACL checks return early and the user durably appends edges into V's <V>_out_edges/<V>_in_edges buckets, silently corrupting graph adjacency they should not be able to touch. No public exploit code is identified, but the advisory describes the mechanism precisely enough to reproduce.