{"answers":{"affected":"2 open source packages ship an affected version, including surrealdb.","exploited":"There is no known exploitation of GHSA-h5rg-8p7f-47g2 in the wild and no public exploit code.","fix":"Upgrade surrealdb to 3.1.5 or later.","what":"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."},"fix_prompt":"Check this codebase for GHSA-h5rg-8p7f-47g2 and fix it if it is affected.\n\nWhat 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.\nExploitation: There is no known exploitation of GHSA-h5rg-8p7f-47g2 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- surrealdb (crates.io): affected all versions; fixed in 3.1.5\n- surrealdb (crates.io): affected all versions; fixed in 3.1.5\n\nTask:\n1. 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.\n2. 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.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-h5rg-8p7f-47g2/ (Markdown: https://insights.sbomify.com/GHSA-h5rg-8p7f-47g2/index.md)","id":"GHSA-h5rg-8p7f-47g2","markdown":"https://insights.sbomify.com/GHSA-h5rg-8p7f-47g2/index.md","name":"GHSA-h5rg-8p7f-47g2","record":{"aliases":[],"analysis":{"component_type":"database","fix_type":"upgrade","impacts":["security_bypass","data_read"],"network_reachable":"yes","non_default_config":false,"product_category":"SurrealDB database","requires_auth":"high_privilege","summary":"A high-privilege user can trigger SSRF in SurrealDB by configuring a malicious JWKS URL that redirects to internal services, bypassing network allowlists.","user_interaction":"not_required","vuln_class":"ssrf"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"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.\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`","ecosystems":["crates.io"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"SurrealDB: SSRF via JWKS URL — Redirect Following in JWT Key Fetch","id":"GHSA-h5rg-8p7f-47g2","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"crates.io","product":null,"products":[],"type":"ssrf","year":"2026"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"crates.io","fixed":["3.1.5"],"introduced":["0"],"last_affected":[],"package":"surrealdb","purl":null,"source":"GHSA-h5rg-8p7f-47g2"},{"ecosystem":"crates.io","fixed":["3.1.5"],"introduced":["0"],"last_affected":[],"package":"surrealdb","purl":"pkg:cargo/surrealdb","source":"GHSA-h5rg-8p7f-47g2"}],"products":null,"published":"2026-06-19","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"A high-privilege user can trigger SSRF in SurrealDB by configuring a malicious JWKS URL that redirects to internal services, bypassing network allowlists.","url":"https://insights.sbomify.com/GHSA-h5rg-8p7f-47g2/"}