GHSA-mhv5-88p6-w4c3: SurrealDB 3.1.0 before 3.3.0 SSRF via Port-Specific --deny-net Host Aliasing Bypass
SurrealDB 3.1.0 before 3.3.0 contains a server-side request forgery vulnerability in network-capability matching because port-specific --deny-net rules (HOST:PORT or IP:PORT) match only a literal host string, while the resolved-IP check discards the port. Authenticated users can call http:: functions with a hostname resolving to a denied IP, or the IP of a denied hostname, to reach blocked internal services.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
SurrealDBto a version that resolves this vulnerability.Fixed in 3.3.0
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated SurrealDB user who can invoke http::* functions can exploit the bypass. The issue is relevant where port-specific --deny-net rules are relied on to block access to internal services.
Are default deployments affected?
The described bypass specifically depends on port-specific --deny-net entries in HOST:PORT or IP:PORT form. The provided information does not establish impact for deployments that do not use those rules.
What should be done if upgrading is not immediately possible?
Do not rely on port-specific --deny-net rules as the sole control for preventing http::* access to blocked internal services. Restrict authenticated users' ability to invoke http::* functions and apply network-level controls to prevent the server from reaching sensitive internal endpoints.
How can I determine whether my deployment is exposed?
Check whether the deployment is running SurrealDB 3.1.0 before 3.3.0, permits authenticated users to call http::* functions, and uses HOST:PORT or IP:PORT --deny-net rules. Such rules can be bypassed by using a hostname that resolves to a denied IP or an IP address for a denied hostname.