Listen to this Post
SurrealDB, a multi-model database, allows administrators to define access methods using JSON Web Keys (JWKS) for JWT or record access authentication. When configured with a JWKS URL, the server fetches the JSON Web Key Set (JWKS) document from that endpoint to validate incoming tokens. This fetch operation is performed by a bare `reqwest` HTTP client, which, by default, automatically follows HTTP redirects.
A critical flaw exists in how the server validates network capabilities during this process. The network capability check, implemented in `core/src/iam/jwks.rs` via the `check_capabilities_url` function, is only applied to the initially configured URL. If the server is started with `–allow-net` to permit access to a specific, trusted JWKS host, that host can be malicious or compromised.
An attacker with the required `Owner` role at the database level (or above) can exploit this by defining an access method that points to an allowlisted host they control. This controlled host is configured to respond with an HTTP 3xx redirect (e.g., 301 or 302). The `Location` header in the redirect points to an internal or restricted address, such as a cloud metadata service (169.254.169.254), a loopback address (127.0.0.1), or an internal service on a private network. Because the `reqwest` client follows redirects without re-evaluating the new target against the network allowlist/denylist, the server-side request is forwarded to the blocked destination, resulting in a Server-Side Request Forgery (SSRF).
This vulnerability is distinct from the protected `HttpClient` used by the `http::` functions, which were hardened in version 3.1.0 to re-check every redirect hop. The JWKS fetcher, however, uses its own client and was not covered by this hardening.
DailyCVE Form
Platform: SurrealDB
Version: < 3.1.5
Vulnerability: SSRF
Severity: Medium
date: 2025-04-10
Prediction: 2025-04-11
What Undercode Say
The vulnerability allows an authenticated attacker to bypass network restrictions and perform internal network reconnaissance. The fix involves hardening the JWKS fetcher to apply a redirect policy that re-validates every redirect target against the configured network capabilities.
Analytics
- Vulnerable Code Path: `core/src/iam/jwks.rs` -> `check_capabilities_url` -> `reqwest::get` (follows redirects)
- Fixed Code Path: `core/src/iam/jwks.rs` -> redirect policy re-validates each hop -> caps at `max_http_redirects`
– Attack Vector: Network - Authentication Required: Yes (Owner role)
Exploit
An attacker with Owner privileges can execute the following steps:
1. Set up a Malicious JWKS Host: Deploy a server on a public IP that is allowed by the target SurrealDB’s `–allow-net` flag.
2. Configure Redirect: The malicious server is configured to respond to any request with an HTTP 301 or 307 redirect. The `Location` header points to a restricted internal IP, such as http://169.254.169.254/latest/meta-data/`.
3. Define Malicious Access Method: In SurrealDB, the attacker runs a query to define a JWT or record access method, specifying the URL of their malicious server as the JWKS endpoint.
DEFINE ACCESS malicious TYPE JWT URL 'http://malicious.example.com/jwks';
4. Trigger the Fetch: The server attempts to fetch the JWKS from the provided URL. The `reqwest` client follows the redirect to the internal metadata service, bypassing the network deny-list.
The fetch is blind, meaning the response body is not returned to the attacker. However, the attacker can infer the existence and liveness of internal hosts and ports based on response-timing differences, as the fetch is bounded by a 1-second timeout.
<h2 style="color: blue;">Protection</h2>
- Patch: Upgrade to SurrealDB version 3.1.5 or later.
- Workarounds:
- Restrict the `Owner` role to only trusted operators.
- Enforce egress filtering at the network layer to block access to link-local (169.254.0.0/16) and other internal IP ranges.–allow-net
- Configure access methods to use only trusted JWKS hosts that do not redirect, or use locally defined keys instead of a remote JWKS.
<h2 style="color: blue;">Impact</h2>
- What an attacker can do:
- Bypass/–deny-net` restrictions.
– Access cloud metadata services, loopback interfaces, and internal services.
– Infer the existence and liveness of internal hosts and ports via timing differences.
– What an attacker cannot do:
– Read the response from the internal service (the fetch is blind).
– Modify data or affect availability (limited to a single GET request).
🎯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
