ArcadeDB EUVD-2026-82892

Requires an authenticated ArcadeDB account (PR:L) with the ability to invoke the IMPORT DATABASE statement or server commands that fetch a remote URL. The attacker must supply a hostname resolving to an IPv6 transition address - NAT64, 6to4, or Teredo - encoding an RFC 1918 or loopback IPv4 target, which the pre-26.9.1 SSRF guard fails to validate. Meaningful impact depends on the deployment having reachable internal services or, most significantly, a cloud instance metadata endpoint (e.g., 169.254.169.254) accessible from the ArcadeDB host. Limiting factors: valid credentials are required (not unauthenticated), the URL-fetching command must be permitted for the account, and the internal targets must actually exist and be network-reachable from the server.

This is a moderate, credentialed SSRF (CWE-918) that should be treated as a medium priority rather than an urgent one. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, score 5.3) is internally consistent with the description: network-reachable but requiring authentication (PR:L) and low complexity, with impact modeled primarily on subsequent internal systems (SC:L/SI:L/SA:L) rather than the ArcadeDB host itself (VC:N/VI:L/VA:N). No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so the real-world exploitation signal is weak - exploitation status is 'no public exploit identified at time of analysis.' The signals do not conflict: a low/absent exploitation probability aligns with a bug that requires valid credentials and a specific fetch-triggering command. The main risk amplifier not captured by the base score is the explicit mention of cloud metadata endpoints - in a cloud deployment, SSRF to a metadata service can yield IAM credentials, which would elevate real confidentiality impact well beyond the vendor's VC:N. That environmental factor, not the base metric, is what defenders should weigh.

An authenticated ArcadeDB user issues an IMPORT DATABASE or server command pointing at a URL whose hostname resolves to an IPv6 transition address (NAT64, 6to4, or Teredo) that embeds an RFC 1918 or loopback IPv4 payload, bypassing the SSRF guard. The server then connects to an internal service or the cloud metadata endpoint (e.g., 169.254.169.254) on the attacker's behalf, potentially exposing internal APIs or instance credentials. No public exploit code is identified at time of analysis, though the bypass technique is well-documented.