ArcadeDB CVE-2026-93595

Requires a valid authenticated ArcadeDB account (PR:L) with network reach to the instance, and the AI chat endpoints exposing the query_database tool must be enabled/reachable. Exploitation is only meaningful when per-type or per-bucket ACLs are actually configured to restrict certain types/buckets from the attacker - those denials are what the tool silently no-ops. Limiting factors: authentication is mandatory (not a remote-unauthenticated bug), the AI assistant surface must be deployed, and impact is confined to reading otherwise-denied data (no write or availability effect). Fixed in ArcadeDB 26.9.1.

This is a genuine but bounded authorization flaw, not a high-CVSS-low-real-risk case. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and CWE-862 describe an authenticated network-reachable missing-authorization bug: the query_database tool exposed via ArcadeDB's AI chat endpoints fails to bind the authenticated principal to DatabaseContext, so per-type/per-bucket ACL checks silently no-op. Impact is confidentiality-only (VC:H, VI:N/VA:N) - attackers read data they are explicitly denied at the per-type level but cannot write or degrade availability. No EPSS score, no CISA KEV listing, and no public proof-of-concept were provided, so this is no public exploit identified at time of analysis; exploitation is authenticated (PR:L) and gated on the AI chat feature being enabled and on ACLs actually being configured to restrict data. The 'Authentication Bypass' tag conflicts with the underlying facts - the attacker is already an authenticated principal and bypasses per-type authorization, so this is an access-control/authorization bypass, not authentication bypass. Priority is moderate: real data-exfiltration primitive that defeats intended tenant/type isolation, but limited to confidentiality, requiring valid credentials and an enabled AI chat surface.

An authenticated low-privilege ArcadeDB user who is denied direct read access to a sensitive type or bucket opens the AI chat assistant and prompts it to run queries against those restricted types through the query_database tool. Because the tool never binds the principal to DatabaseContext, the per-type/per-bucket ACL checks no-op and the assistant returns data the user could never retrieve through normal query endpoints. No public exploit code is identified, but the technique requires only crafted natural-language prompts, so exploitation complexity is low.