SurrealDB EUVD-2026-115953

Requires: (1) SurrealDB 3.1.0 through 3.2.x with outbound HTTP enabled so the http::* functions (http::get/post/put/patch/delete) are callable; (2) an authenticated caller (PR:L) permitted to invoke those functions; and (3) that the deployment relies on PORT-SPECIFIC egress deny rules of the form --deny-net HOST:PORT or --deny-net IP:PORT to protect internal services. The bypass is triggered by naming the denied target through a different alias that resolves to the same address (a hostname for a denied IP, or the IP for a denied hostname). Key LIMITS: bare-IP deny rules such as --deny-net 127.0.0.1 (stored as an IPNet/32) are NOT affected and block both forms; deployments not using port-bearing Host-form deny rules are unaffected. Impact WIDENS in deny-list mode (--allow-net unrestricted / --allow-all), where the resolved private-address filter is skipped, exposing loopback/RFC1918/link-local and cloud-metadata targets.

This is a genuine but bounded issue, best read as a defense-in-depth bypass rather than a high-urgency flaw. The CVSS 4.0 base vector supplied (AV:N/AC:L/AT:N/PR:L/UI:N) scores 5.3 Medium and models no impact to SurrealDB itself (VC:N/VI:N/VA:N) with only low subsequent-system impact (SC:L/SI:L/SA:L) - consistent with SSRF that reaches OTHER internal services rather than compromising the database. Note a real conflict in the inputs: the vendor GHSA advisory estimates a higher CVSS:3.1 of ~6.5 with C:H/I:N/A:N (full confidentiality of the reached internal service), whereas the NVD-style 4.0 vector rates subsequent confidentiality only Low - treat the true read impact as somewhere between, depending on what the exploitable internal service exposes. There is no CISA KEV entry (not confirmed actively exploited) and no EPSS score was provided, so widespread-exploitation probability cannot be quantified from the data. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with a patch-promptly posture. The practical risk is sharply gated: it only matters where an operator relies specifically on port-specific --deny-net HOST:PORT/IP:PORT rules to fence internal services AND exposes http::* functions to authenticated users; bare-IP deny rules (e.g. --deny-net 127.0.0.1) are not affected. Reported by VulnCheck with a vendor-published root-cause and reproduction, so the technical validity is well established even though mass exploitation is unproven.

An operator runs SurrealDB 3.1.0-3.2.x with outbound HTTP enabled and relies on a port-specific rule such as --deny-net 127.0.0.1:9999 to block an internal admin service. An authenticated user invokes http::get('http://localtest.me:9999/') - a hostname alias resolving to the same denied 127.0.0.1 - which is not caught by the literal host comparison and whose port is discarded at the resolved-IP check, so the request reaches the blocked service and returns its response. The vendor GHSA advisory publishes full, working reproduction steps for this (network vector, low complexity, no user interaction), though it is not packaged as a standalone exploit tool and is not listed in CISA KEV.