Live › vulnerability › CVE-2026-121420
SurrealDB 3.2.0 before 3.3.0 fails to detect private IPv4 addresses wrapped in NAT64, 6to4, and Teredo IPv6 addresses when filtering outbound requests. An authenticated user can use SurrealQL HTTP functions to reach localhost, internal services, or cloud metadata endpoints.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 15:21 UTC. All times on this page are UTC.
Deployments of SurrealDB 3.2.x where authenticated users can run SurrealQL HTTP functions that make outbound requests. The risk is greatest where the server can reach internal networks or cloud metadata endpoints. Instances that do not allow user-supplied HTTP calls, or that restrict egress, are less exposed.
No product ranges from the sources yet.
surreal version, and treat 3.2.0 up to but not including 3.3.0 as exposed.http::get in your deployment.3.3.0 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-121420")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.