Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🦀
🦀 crates.io
Not in CISA KEV
MEDIUM severity

SurrealDB vulnerable to Denial of Service due to nested types annotationsGHSA-q8qp-67f9-wr3f

MEDIUMFix: surrealdb/surrealdb@61d509b

GHSA-q8qp-67f9-wr3f is a medium-severity (CVSS 6.5) vulnerability in surrealdb. A fix is available for surrealdb — see the affected versions and patch details below.

Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Jul 1, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🦀surrealdb

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

The SurrealDB type/kind parser did not enforce the configured recursion depth limit when parsing nested type annotations. The expression parser already enforced the limit for analogous constructs; the kind parser omitted it. An authenticated attacker could send a query with deeply nested type annotations (e.g., array<option<array<option<...>>>>) and exhaust server memory, crashing the process.

This is an incomplete fix for GHSA-6r8p-hpg7-825g, which addressed the same class of bug in the expression parser but did not cover the kind/type annotation parser code path.

Impact

An authenticated user with query execution privileges can crash a SurrealDB server with a single WebSocket message containing deeply nested type annotations.

Patches

A patch has been introduced that wraps parse_concrete_kind and the OPTION<...> arm of parse_inner_kind with enter_object_recursion!, bounding the recursive cycle parse_concrete_kind → parse_inner_kind → parse_inner_single_kind → parse_concrete_kind at the configured object_recursion_limit (default 100). Regression tests cover both cast and DEFINE FIELD paths.

  • Versions 3.1.0 and later are not affected by this issue.

Workarounds

Restrict the ability of untrusted users to execute arbitrary queries via the --deny-arbitrary-query capability flag for the affected user classes (guest, record, or system). Disabling untrusted access to the WebSocket /rpc endpoint also prevents exploitation; the HTTP /sql endpoint's 1 MiB body limit constrains nesting to a depth where OOM is not feasible.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iosurrealdball versions3.1.0cargo update -p surrealdb --precise 3.1.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for surrealdb, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update surrealdb to 3.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-q8qp-67f9-wr3f is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

The SurrealDB type/kind parser did not enforce the configured recursion depth limit when parsing nested type annotations. The expression parser already enforced the limit for analogous constructs; the kind parser omitted it. An authenticated attacker could send a query with deeply nested type annotations (e.g., `array<option<array<option<...>>>>`) and exhaust server memory, crashing the process. This is an incomplete fix for [GHSA-6r8p-hpg7-825g](https://github.com/surrealdb/surrealdb/security/advisories/GHSA-6r8p-hpg7-825g), which addressed the same class of bug in the expression parser but
O3 Security · Impact-Aware SCA

Is GHSA-q8qp-67f9-wr3f in your dependencies?

Find it across crates.io, including transitive dependencies.

SurrealDB vulnerable to Denial of Service due to nested…