CVE-2025-71390: SurrealDB Auth Bypass Vulnerability

CVE-2025-71390 Overview

CVE-2025-71390 is a network access control bypass in SurrealDB that allows authenticated users to circumvent --deny-net restrictions through DNS resolution. The flaw resides in the http::* function family, which validates the user-supplied hostname but fails to re-check the resolved IP address against the deny list before issuing the outbound HTTP request. An authenticated user can call http::get(<url>) or similar functions with a hostname that resolves to a restricted internal IP, and the server executes the request anyway. This weakness maps to CWE-863: Incorrect Authorization and enables server-side request forgery against internal endpoints.

Critical Impact
Authenticated users can reach denied internal network endpoints, potentially retrieving or altering sensitive information and credentials exposed on the host network.

Affected Products

SurrealDB versions before 2.2.6
SurrealDB versions before 2.3.6 and before 2.1.8
SurrealDB 3.0.0-alpha.7 and earlier

Discovery Timeline

2026-07-18 - CVE-2025-71390 published to NVD
2026-07-21 - Last updated in NVD database

Technical Details for CVE-2025-71390

Vulnerability Analysis

SurrealDB exposes a family of http::* built-in functions such as http::get, http::post, http::put, http::patch, and http::delete that let query authors issue outbound HTTP requests from within SurrealQL. Operators can restrict which destinations these functions may reach by starting the server with the --deny-net flag, which accepts hosts, IPs, or CIDR ranges.

The enforcement logic inspects the hostname literal supplied in the URL argument. It does not re-evaluate the destination after DNS resolution. When the client library resolves the hostname to an IP address, that IP is passed directly to the HTTP transport without a second policy check. An attacker-controlled DNS name pointing to a denied IP therefore passes the guard and reaches the intended internal target.

The response body and headers are returned to the caller, turning the database into a full SSRF (Server-Side Request Forgery) proxy for any authenticated principal that can invoke the http::* namespace.

Root Cause

The deny-list evaluation operates on the pre-resolution hostname string rather than on the resolved socket address. There is no post-resolution verification step, and no pinning of the resolved IP to the value approved by the policy engine. This is a classic time-of-check versus time-of-use gap between the authorization decision and the network syscall.

Attack Vector

An authenticated user with permission to execute http::* functions registers or references a DNS record under their control. The record resolves to an IP the operator intended to block, such as 169.254.169.254 (cloud instance metadata), 127.0.0.1, or an RFC1918 host inside the deployment. The user then invokes the HTTP function with the attacker-controlled hostname. SurrealDB accepts the hostname, resolves it, and executes the request against the denied address, returning the response to the query.

Typical targets include cloud metadata services, internal admin panels, unauthenticated Redis or Elasticsearch instances, and Kubernetes API endpoints. Refer to the GitHub Security Advisory GHSA-m3c3-78fh-w3w7 and the VulnCheck Advisory for further technical detail.

Detection Methods for CVE-2025-71390

Indicators of Compromise

Outbound HTTP requests originating from the SurrealDB process to RFC1918, loopback, or link-local addresses such as 169.254.169.254.
SurrealDB query logs containing http::get, http::post, http::put, http::patch, or http::delete calls with unfamiliar or attacker-registered hostnames.
DNS queries from the database host resolving external names to internal IP ranges (DNS rebinding pattern).

Detection Strategies

Correlate SurrealDB audit logs with egress firewall logs to identify HTTP requests that should have been blocked by --deny-net.
Alert on database processes making requests to cloud metadata IPs or internal management interfaces.
Baseline the set of hostnames legitimately used by http::* calls and flag deviations.

Monitoring Recommendations

Enable verbose query logging on SurrealDB and forward it to a centralized log store for retention and search.
Monitor DNS responses from resolvers used by the database host for public-to-private address mappings.
Track authentication events for accounts holding http::* execution privileges and review their query history regularly.

How to Mitigate CVE-2025-71390

Immediate Actions Required

Upgrade SurrealDB to 2.2.6, 2.3.6, or 2.1.8 on the appropriate release branch, or to a fixed 3.0.0 build later than alpha.7.
Restrict who can invoke http::* functions by reviewing role and permission grants for authenticated users.
Enforce egress filtering at the network layer so that the SurrealDB host cannot reach metadata services or internal management planes regardless of application-level controls.

Patch Information

The SurrealDB maintainers released fixed builds 2.2.6, 2.3.6, and 2.1.8. Details are published in the GitHub Security Advisory GHSA-m3c3-78fh-w3w7. Operators running 3.0.0 alpha builds should move to a release later than 3.0.0-alpha.7.

Workarounds

Disable the http::* function namespace for all non-administrative roles until patching is complete.
Deploy SurrealDB inside a network segment with a default-deny egress policy that blocks link-local, loopback, and RFC1918 destinations at the firewall.
Configure the host resolver or a local DNS proxy to refuse responses that map public names to private address space, mitigating DNS rebinding.

bash

# Example host-level egress restriction using iptables on the SurrealDB server
iptables -A OUTPUT -m owner --uid-owner surrealdb -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner surrealdb -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner surrealdb -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner surrealdb -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner surrealdb -d 192.168.0.0/16 -j REJECT