# GHSA-h5rg-8p7f-47g2: SurrealDB: SSRF via JWKS URL — Redirect Following in JWT Key Fetch

> A high-privilege user can trigger SSRF in SurrealDB by configuring a malicious JWKS URL that redirects to internal services, bypassing network allowlists.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** An administrator
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 19 Jun 2026

## What is GHSA-h5rg-8p7f-47g2?

GHSA-h5rg-8p7f-47g2 is a server-side request forgery vulnerability in surrealdb, published on 19 Jun 2026. An attacker needs administrator access to exploit it, with no action from the victim.

### Official description

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

The 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`.

- Versions prior to 3.1.5 are vulnerable.

### Workarounds

- Restrict the Owner role to trusted operators.
- 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.
- Configure access methods to use only trusted JWKS hosts that do not redirect, or use locally defined keys instead of a remote JWKS.

### References

- [SurrealDB Documentation — Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities)
- [SurrealQL Documentation — DEFINE ACCESS](https://surrealdb.com/docs/surrealql/statements/define/access)
- `fix(iam): prevent SSRF in JWKS fetch by re-validating redirect targets`

## Which versions are affected by GHSA-h5rg-8p7f-47g2?

2 open source packages ship an affected version, including surrealdb.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `surrealdb` | crates.io | All versions | 3.1.5 |
| `surrealdb` | crates.io | All versions | 3.1.5 |

## How do I fix GHSA-h5rg-8p7f-47g2?

Upgrade surrealdb to 3.1.5 or later.

## Is GHSA-h5rg-8p7f-47g2 being exploited?

There is no known exploitation of GHSA-h5rg-8p7f-47g2 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-h5rg-8p7f-47g2 and fix it if it is affected.

What it is: GHSA-h5rg-8p7f-47g2 is a server-side request forgery vulnerability in surrealdb, published on 19 Jun 2026. An attacker needs administrator access to exploit it, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-h5rg-8p7f-47g2 in the wild and no public exploit code.

Affected packages and fixed versions:
- surrealdb (crates.io): affected all versions; fixed in 3.1.5
- surrealdb (crates.io): affected all versions; fixed in 3.1.5

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-h5rg-8p7f-47g2/ (Markdown: https://insights.sbomify.com/GHSA-h5rg-8p7f-47g2/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-h5rg-8p7f-47g2

---
From sbomify Insights: https://insights.sbomify.com/GHSA-h5rg-8p7f-47g2/
Summaries are generated and may contain mistakes; the official description above is the record.