GHSA-h5rg-8p7f-47g2: SurrealDB SSRF Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-h5rg-8p7f-47g2",
  "modified" : "2026-06-19T22:10:45Z",
  "published" : "2026-06-19T22:10:45Z",
  "aliases" : [ ],
  "summary" : "SurrealDB: SSRF via JWKS URL — Redirect Following in JWT Key Fetch",
  "details" : "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.\n\n### Impact\n\nWhat an attacker **can** do:\n\n- 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`.\n- Infer the existence and liveness of internal hosts and ports from response-timing differences (bounded by the 1-second fetch timeout).\n\nWhat it **can't** do:\n\n- 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.\n- Modify data or affect availability (a single GET request).\n\n### Patches\n\nThe JWKS fetcher now applies a redirect policy that re-validates every redirect target against the configured network capabilities (mirroring `check_capabilities_url`) and caps redirects at `max_http_redirects`.\n\n- Versions prior to 3.1.5 are vulnerable.\n\n### Workarounds\n\n- Restrict the Owner role to trusted operators.\n- Enforce egress filtering at the network layer (block link-local `169.254.0.0/16` and internal ranges) so redirect targets are unreachable regardless of in-process checks.\n- Configure access methods to use only trusted JWKS hosts that do not redirect, or use locally defined keys instead of a remote JWKS.\n\n### References\n\n- [SurrealDB Documentation — Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities)\n- [SurrealQL Documentation — DEFINE ACCESS](https://surrealdb.com/docs/surrealql/statements/define/access)\n- `fix(iam): prevent SSRF in JWKS fetch by re-validating redirect targets`",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "surrealdb"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "3.1.5"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-h5rg-8p7f-47g2"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/surrealdb/surrealdb"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-918" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-06-19T22:10:45Z",
    "nvd_published_at" : null
  }
}