CVE-2025-71398 Overview
CVE-2025-71398 is a Server-Side Request Forgery (SSRF) vulnerability affecting SurrealDB versions prior to 2.2.2. The flaw resides in SurrealDB's HTTP functions, which fail to validate the destination of HTTP redirects. Authenticated users can bypass the deny-net network restriction by pointing a request at an attacker-controlled server that issues a redirect to a blocked internal IP address. The database then follows the redirect and issues the request against the restricted target. This enables SSRF against internal endpoints and cloud metadata services, exposing sensitive data reachable from the SurrealDB host [CWE-918].
Critical Impact
Authenticated attackers can bypass network egress controls in SurrealDB to reach internal-only services and exfiltrate sensitive information via HTTP redirects.
Affected Products
- SurrealDB versions before 2.2.2
- Deployments relying on the deny-net allowlist to protect internal networks
- SurrealDB HTTP function callers (http::get, http::post, http::put, http::patch, http::delete, http::head)
Discovery Timeline
- 2026-07-18 - CVE-2025-71398 published to NVD
- 2026-07-21 - Last updated in NVD database
Technical Details for CVE-2025-71398
Vulnerability Analysis
SurrealDB exposes HTTP functions within its query language, allowing SurrealQL scripts to issue outbound HTTP requests. Operators can restrict these calls with the deny-net configuration, which blocks requests to specified networks such as 127.0.0.0/8, 169.254.169.254, or internal RFC1918 ranges. Prior to version 2.2.2, this policy is evaluated only against the initial request URL. When the remote server responds with a 3xx redirect, the HTTP client follows the Location header without re-applying the deny-net check. An authenticated user who can invoke HTTP functions can host a public redirector that forwards traffic into blocked network space, turning SurrealDB into an SSRF proxy.
Root Cause
The root cause is missing validation on redirect targets in SurrealDB's HTTP client wrapper. Network access policy is enforced at request construction time, but the follow-redirect logic reuses the same client without re-checking each hop against the deny list. This is a classic instance of CWE-918, Server-Side Request Forgery, caused by trusting the transport layer to honor a policy that only applied to the first URL.
Attack Vector
Exploitation requires an authenticated SurrealDB account with permission to execute HTTP functions. The attacker points a SurrealQL HTTP call at a public server they control. That server responds with an HTTP 302 redirect whose Location header targets an internal address, such as a cloud instance metadata endpoint or an internal admin API. SurrealDB follows the redirect and returns the response body to the caller. The attacker can then read cloud credentials, internal service data, or other information reachable from the database host. See the GitHub Security Advisory and the VulnCheck Advisory for vendor detail.
Detection Methods for CVE-2025-71398
Indicators of Compromise
- Outbound HTTP requests from the SurrealDB host to unfamiliar external domains followed by inbound requests to internal-only IP ranges from the same process.
- SurrealQL query logs containing calls to http::get, http::post, or related functions with URLs pointing to third-party or newly registered domains.
- Access log entries on internal services or 169.254.169.254 metadata endpoints originating from the SurrealDB service account.
Detection Strategies
- Inspect SurrealDB query and audit logs for HTTP function invocations targeting external hosts, then correlate with egress firewall logs for redirect chains ending in RFC1918 or link-local space.
- Deploy egress network monitoring that flags any request from the database host to cloud metadata addresses such as 169.254.169.254 or metadata.google.internal.
- Alert on 3xx responses received by the SurrealDB process where the redirect target resolves to a private, loopback, or link-local address.
Monitoring Recommendations
- Ingest SurrealDB logs into a centralized SIEM and build detections around HTTP function usage per authenticated user.
- Baseline expected outbound destinations for SurrealDB and alert on deviations, especially requests to ephemeral or short-lived domains.
- Track authentication events for accounts that gain the privilege to run HTTP functions and review any new grants.
How to Mitigate CVE-2025-71398
Immediate Actions Required
- Upgrade SurrealDB to version 2.2.2 or later on all nodes.
- Audit existing SurrealDB accounts and revoke HTTP function privileges from users who do not require them.
- Review query and access logs since deployment for suspicious use of http:: functions against external domains.
Patch Information
The vendor fixed CVE-2025-71398 in SurrealDB 2.2.2 by validating redirect targets against the deny-net policy on every hop. Refer to the GitHub Security Advisory GHSA-5q9x-554g-9jgg for the official fix commit and release notes. Operators should apply this update before relaxing any compensating controls.
Workarounds
- Place SurrealDB behind an egress proxy or firewall that enforces destination allowlists at the network layer, preventing redirect-based reach into internal ranges.
- Restrict SurrealDB permissions so that only trusted service accounts can execute HTTP functions.
- Block outbound access from the database host to cloud instance metadata endpoints and internal management networks using host-based firewall rules.
# Example iptables rules to block SurrealDB egress to metadata and RFC1918 targets
iptables -A OUTPUT -m owner --uid-owner surrealdb -d 169.254.169.254 -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
iptables -A OUTPUT -m owner --uid-owner surrealdb -d 127.0.0.0/8 -j REJECT
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

