ArcadeDB EUVD-2026-107008

Requires a valid authenticated account on at least one database on the instance (PR:L), and the Bolt protocol handler/port must be enabled and network-reachable to the attacker. Exploitation is a single SHOW DATABASES query - no special complexity, user interaction, or non-default feature beyond Bolt being exposed. The limiting factor is the credential requirement: an unauthenticated outsider cannot trigger this, so realistic risk is confined to existing authenticated users (e.g., one tenant enumerating other tenants) or an attacker who has already obtained database credentials. Impact is limited to disclosure of database names (tenant/project identifiers), not their contents.

This is a genuinely low-to-moderate priority issue, and the signals are internally consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) describes a network-reachable, low-complexity attack that nevertheless requires existing credentials (PR:L) and yields only limited confidentiality impact (VC:L), with no integrity or availability impact and no scope change (VI:N/VA:N/SC:N). CWE-862 (Missing Authorization) matches the description precisely: an already-authenticated user crosses an authorization boundary to read metadata they should not see. No EPSS score, KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is an information-disclosure/reconnaissance aid (leaking tenant or project database names), not direct compromise. The low CVSS of 5.3 accurately reflects real-world risk here - this is a confidentiality-only metadata leak gated behind valid credentials, not a high-CVSS-but-overstated finding nor an understated one. Note the 'Authentication Bypass' tag is a mischaracterization: exploitation requires valid authentication (PR:L) and the flaw is a missing authorization check, not an authentication bypass.

An attacker who already holds valid credentials to any single ArcadeDB database (for example, a low-privilege tenant in a multi-tenant deployment) connects over the Bolt protocol port and issues a SHOW DATABASES query. Because the Bolt handler fails to enforce per-database authorization, the response enumerates the names of all databases on the instance, revealing other tenants' or projects' identifiers that can seed further targeted attacks. No public exploit code was identified at time of analysis, though the query itself is trivial to issue with a standard Bolt client.