Summary
A server-side request forgery vulnerability in SurrealDB allows authenticated users to bypass deny-net restrictions when HTTP functions follow redirects without validating the final destination.
An attacker may use a publicly reachable server to redirect requests toward blocked internal addresses, potentially exposing sensitive services and information.
Affected context
The vulnerability occurs in SurrealDB deployments that expose HTTP functions to authenticated users and rely on deny-net restrictions to prevent requests to protected or private network destinations. The risk is present when redirect targets are not validated against the same network access policy applied to the original URL.
Exploit preconditions
- Attack surface: SurrealDB HTTP functions that can make outbound requests
- Required access: Authenticated access sufficient to invoke or influence an HTTP function
- Trigger point: Processing an HTTP response that redirects the request to another destination
- Why exploitation is possible: The redirect destination may bypass deny-net checks and reach otherwise blocked internal addresses
Why this happens
The underlying issue is incomplete validation of redirect destinations in an outbound HTTP request flow. A request may initially pass network restrictions, while a subsequent redirect is followed without reapplying those restrictions to the new destination.
This behavior maps to CWE-918: Server-Side Request Forgery, where attacker-influenced server-side requests can reach unintended internal or protected resources.
Potential impact
- Internal services may be accessed from the SurrealDB server
- Sensitive endpoint responses or metadata could be disclosed
- Cloud or infrastructure credentials may be exposed if reachable through internal services
- Network segmentation and deny-net controls may be weakened
- Internal applications could receive unauthorized requests from the database environment
General mitigation guidance
Mitigation generally focuses on applying outbound network policy consistently across the complete request lifecycle, including every redirect.
Common defensive patterns include:
- Validating each redirect destination before following it
- Using secure-by-default HTTP clients that disable automatic redirects or enforce destination policies
- Resolving hostnames and evaluating resulting addresses against deny lists and allowlists
- Restricting HTTP function access to trusted users and approved use cases
- Applying egress firewall controls and network segmentation outside the application
- Running the database service with only the minimum network and system privileges required
How teams detect issues like this
Organizations can look for SSRF risks through:
- Static analysis of HTTP clients that automatically follow redirects
- Code review checks for destination validation applied only to initial URLs
- Tests covering redirects to private, loopback, link-local, and restricted network ranges
- Monitoring outbound requests from database services to unexpected internal destinations
- Network policy enforcement and alerting for denied or anomalous egress attempts
- Automated security review tools that flag server-side request flows lacking destination controls
