SurrealDB: SSRF via JWKS URL — Redirect Following in JWT Key Fetch
Date: 2026-06
Affected: rust/surrealdb
Attack vector: ssrf
Category: vulnerability-disclosure
Severity: Medium
CWE: CWE-918
CVSS: 4.1 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N)

SurrealDB fetches the JWKS document for a JWT or record access method using a bare `reqwest` client that follows HTTP redirects by default. The network capability check in `core/src/iam/jwks.rs` (`check_capabilities_url`) is applied only to the originally configured URL; redirect targets are not re-validated. An `--allow-net`-permitted JWKS host that returns a `3xx Location` can therefore redirect the request to an address the allowlist was meant to block, resulting in a server-side request forgery (SSRF). The protected `HttpClient` used by `http::*` functions re-checks every redirect hop and was hardened in 3.1.0, but the JWKS fetcher uses its own client and was not covered. ### Impact What an attacker **can** do: - With the **Owner** role at database level or above (the minimum required to run `DEFINE ACCESS ... TYPE JWT URL` or `TYPE RECORD ... WITH JWT URL`), point an access method at an allowlisted host they control and redirect the server's GET to an otherwise-blocked target — cloud metadata, loopback, internal services — bypassing `--allow-net`/`--deny-net`. - Infer the existence and liveness of internal hosts and ports from response-timing differences (bounded by the 1-second fetch timeout). What it **can't** do: - Read the response: the fetch is blind — the body is only parsed as a JWKS, and a non-JWKS response surfaces as an opaque `InvalidAuth` error. Nothing is returned to the caller. - Modify data or affect availability (a single GET request). ### Patches


Mitigations:

Architectural layers (MAESTRO):