CVE-2026-121420 in SurrealDB
Summary
by MITRE • 11/03/2026
SurrealDB from 3.2.0 before 3.3.0 contains a server-side request forgery vulnerability in the FilteringResolver is_private_ip check that fails to unwrap NAT64, 6to4, and Teredo IPv6 addresses. Authenticated users triggering outbound HTTP requests via SurrealQL http functions can use transition addresses embedding private IPv4 targets to reach localhost, internal services, or cloud metadata endpoints.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
SurrealDB versions prior to 3.3.0 contain a critical server-side request forgery vulnerability within the FilteringResolver component, specifically in its is_private_ip validation logic. This flaw stems from an incomplete implementation of network address classification for IPv6 transition mechanisms. The security check fails to properly unwrap or interpret NAT64, 6to4, and Teredo encapsulated addresses. These protocols are designed to facilitate communication between IPv6-only networks and the legacy IPv4 internet by embedding IPv4 addresses within IPv6 packets. By not decoding these embedded structures before performing private IP range checks, the database engine incorrectly classifies certain internal or localhost targets as public external addresses, thereby bypassing security restrictions intended to prevent outbound requests to sensitive network segments.
The operational impact of this vulnerability is significant for any authenticated user interacting with SurrealDB instances that allow HTTP-based queries via SurrealQL functions. An attacker who has obtained valid authentication credentials can craft specific database queries that utilize these IPv6 transition addresses to route outgoing HTTP requests through the server. Because the validation logic fails to detect the underlying private IPv4 destination, the request is permitted by the firewall rules or application-level filters designed to block access to internal resources. This effectively allows the authenticated user to perform SSRF attacks against localhost services running on the database host, internal corporate network infrastructure that may not be directly accessible from outside, and cloud metadata endpoints such as AWS EC2 instance metadata service or Azure managed identity endpoints.
This vulnerability aligns with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where server-side code makes requests to user-supplied URLs without sufficient validation of the destination address. Furthermore, it maps directly to MITRE ATT&CK technique T1502.004, known as Use Alternative Protocol Encoding: IPv6, which details how attackers exploit alternative protocol encodings like 6to4 or Teredo to evade detection mechanisms that only inspect standard IP headers. The exploitation of this flaw enables lateral movement within a network environment by allowing the attacker to pivot from an authenticated database session into internal service layers that are typically isolated from external access paths.
Mitigation for this vulnerability requires immediate upgrading to SurrealDB version 3.3.0 or later, where the FilteringResolver has been patched to correctly unwrap and validate transition addresses against private IP ranges before allowing outbound connections. In environments where an upgrade is not immediately feasible, administrators should implement strict network segmentation rules at the infrastructure level rather than relying solely on application-level filtering. This includes configuring host-based firewalls to restrict egress traffic from database servers to only explicitly required external domains and blocking access to cloud metadata IPs such as 169.254.169.254 for IPv4 or their IPv6 equivalents. Additionally, deploying a reverse proxy with robust SSRF protection can provide an additional layer of defense by validating the final resolved IP address before forwarding requests to internal services.