SurrealDB CVE-2026-121420

Three conditions must all hold: (1) the attacker is an authenticated SurrealDB user (PR:L) able to trigger outbound HTTP, specifically via SurrealQL http:: functions, webhook deliveries, or OIDC metadata fetches that pass through the FilteringResolver; (2) the SurrealDB host has NAT64, 6to4, or Teredo IPv6 transition connectivity so the crafted transition address actually routes to its embedded IPv4 target - the advisory explicitly scopes the bypass to such hosts, making this the primary limiting factor and a non-default condition for most deployments; (3) the version is in range 3.2.0 up to but not including 3.3.0. The guard correctly handles IPv4-mapped (::ffff:) addresses, so only NAT64 (64:ff9b::/96), 6to4 (2002::/16), and Teredo (2001:0000::/32) wrappers bypass it. Exploitation is further limited to internal/private IPv4 targets reachable from the host (localhost, internal services, cloud IMDS at 169.254.169.254).

This is a genuine but conditional SSRF (CWE-918), not a high-severity emergency. The vendor CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N) scores only 4.8 (medium), and the vuln.today decision label is 'this_month' - not act_now or emergency. Several signals point to limited real-world risk: exploitation requires an authenticated user (PR:L) who can already trigger outbound HTTP via SurrealQL http:: functions, and - critically - the bypass only works 'on hosts with NAT64, 6to4, or Teredo connectivity' per the GHSA advisory, which is a non-default network condition on most deployments. No CISA KEV listing and no EPSS score were provided, and no working exploit code is published, so there is no evidence of active exploitation. One signal to verify: the vendor's vector uses AV:L (local), yet the mechanism is an authenticated user submitting a SurrealQL query that drives an outbound HTTP request, which is more naturally a network-reachable interaction - this AV:L choice should be confirmed with the vendor, as it materially lowers the score. Net: a valid defense-in-depth bypass worth patching on affected SurrealDB instances that permit user-driven outbound HTTP and sit on transition-address-capable networks, but not a widespread-exploitation priority.

An authenticated SurrealDB user who is permitted to invoke SurrealQL http functions (e.g. http::get) issues a request to an IPv6 transition address such as 64:ff9b::7f00:1 (NAT64 wrapping 127.0.0.1) or 2002:a9fe:a9fe:: (6to4 wrapping 169.254.169.254). The is_private_ip SSRF guard only unwraps IPv4-mapped (::ffff:) addresses via to_canonical(), so the transition address passes the filter, and on a host with NAT64/6to4/Teredo connectivity it routes to the embedded private IPv4 target such as cloud metadata (IMDS) or an internal service. No working exploit code is published, though the GHSA and VulnCheck advisories document the exact bypass addresses.