GHSA-65rj-r9fh-jp2v: Surrealdb SurrealDB Vulnerable To Pre-auth Memory Vulnerability

MODERATE
CVSS 5.3
CWE-770
Published
Advisory Summary

GHSA-65rj-r9fh-jp2v is a MODERATE (CVSS 5.3) surrealdb vulnerable to pre-auth memory vulnerability (CWE-770: Allocation of Resources Without Limits or Throttling) affecting Surrealdb libraries in the crates.io ecosystem. The issue involves surrealdb vulnerable to pre-auth memory amplification via unbounded `/sql` websocket frames. Remediation is available by upgrading affected packages to version 3.1.0.

GHSA-65rj-r9fh-jp2v at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-65rj-r9fh-jp2v
Severity MODERATE
CVSS v3.1 Base Score 5.3
CWE Classification CWE-770: Allocation of Resources Without Limits or Throttling
Affected Product Surrealdb
Package Ecosystem crates.io
Published Date
Last Updated

Security Impact

CVSS: 5.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability Low (A:L)

How to Fix GHSA-65rj-r9fh-jp2v

To remediate this vulnerability, upgrade all affected Surrealdb dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

surrealdb fixed: 3.1.0
Upgrade surrealdb to 3.1.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for surrealdb

How to Check if You Are Affected

To determine whether your application is affected by GHSA-65rj-r9fh-jp2v, inspect your project dependencies for Surrealdb:

inspect dependencies for surrealdb

Analyze the terminal output to locate any version of Surrealdb in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.1.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-770: Allocation of Resources Without Limits or Throttling, where the product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. In Surrealdb, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

An anonymous caller could degrade `/sql` availability by streaming WebSocket frames many times larger than the operator-configured per-connection limit. The `/sql` upgrade handler accepted anonymous connections and did not propagate `SURREAL_WEBSOCKET_MAX_MESSAGE_SIZE` to the WebSocket protocol layer — incoming bytes accumulated in the per-connection read buffer before `check_anon` could reject the query, so the memory cost was incurred regardless of whether the caller could ever execute SurrealQL. The same upgrade path also silently ignored `--deny-http sql` and `--deny-arbitrary-query *` for authenticated callers, but that secondary effect does not grant new permissions. ### Impact `SURREAL_WEBSOCKET_MAX_MESSAGE_SIZE` is not applied to anonymous `/sql` connections, so each connection can buffer up to the WebSocket library defaults (16 MiB per frame, 64 MiB per reassembled message) of in-flight bytes regardless of the operator's configured limit. Holding this much memory pinned requires actively streaming bytes into the connection, so an attacker has to maintain bandwidth across many concurrent connections to consume meaningful memory. Within that constraint the result is degraded availability for legitimate `/sql` clients; on memory-constrained deployments the process may be OOM-killed and restarted during the attack rather than denied service outright. Separately, `--deny-http sql` and `--deny-arbitrary-query *` were not enforced on the WebSocket, so SurrealQL operations the operator had configured to refuse could still be issued by any authenticated principal that already held the corresponding data permissions. This is a configuration-correctness defect — the bypass does not grant new permissions. ### Patches A patch has been introduced that performs the two capability checks before calling `on_upgrade` and applies the same per-connection size limits used by `/rpc`. The capability checks enforce the operator's configured deny flags; they do not change what any authenticated principal is permitted to do. - Versions 3.1.0 and later are not affected by this issue. ### Workarounds Affected users who are unable to update should refuse `GET /sql` requests carrying `Upgrade: websocket` at a reverse proxy, or apply per-connection frame size limits at the reverse proxy.

GHSA-65rj-r9fh-jp2v Affected Surrealdb Versions

1 component(s)
Fixed Versions:
3.1.0
Product / Package Ecosystem Affected Versions Fixed Version
surrealdb
crates.io
< 3.1.0
3.1.0

References

Frequently Asked Questions

What is GHSA-65rj-r9fh-jp2v?
GHSA-65rj-r9fh-jp2v is a security vulnerability in Surrealdb involving SurrealDB vulnerable to pre-auth memory amplification via unbounded `/sql` WebSocket frames under CWE-770: Allocation of Resources Without Limits or Throttling.
Which Surrealdb versions are affected?
Affected versions include releases prior to 3.1.0 across affected packages: surrealdb.
What version fixes GHSA-65rj-r9fh-jp2v?
Upgrading to 3.1.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is surrealdb affected?
Yes, surrealdb is affected in releases prior to 3.1.0. Upgrade your dependency to 3.1.0 or later.
What is the CVSS score of GHSA-65rj-r9fh-jp2v?
GHSA-65rj-r9fh-jp2v has a CVSS v3.1 base score of 5.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L.
What CWE is associated with GHSA-65rj-r9fh-jp2v?
GHSA-65rj-r9fh-jp2v is classified under CWE-770: Allocation of Resources Without Limits or Throttling (The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.).
How can I check crates.io dependencies for GHSA-65rj-r9fh-jp2v?
Run the dependency tree command: 'inspect dependencies for surrealdb'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-65rj-r9fh-jp2v",
  "modified" : "2026-07-01T20:15:03Z",
  "published" : "2026-07-01T20:15:03Z",
  "aliases" : [ ],
  "summary" : "SurrealDB vulnerable to pre-auth memory amplification via unbounded `/sql` WebSocket frames",
  "details" : "An anonymous caller could degrade `/sql` availability by streaming WebSocket frames many times larger than the operator-configured per-connection limit. The `/sql` upgrade handler accepted anonymous connections and did not propagate `SURREAL_WEBSOCKET_MAX_MESSAGE_SIZE` to the WebSocket protocol layer — incoming bytes accumulated in the per-connection read buffer before `check_anon` could reject the query, so the memory cost was incurred regardless of whether the caller could ever execute SurrealQL. The same upgrade path also silently ignored `--deny-http sql` and `--deny-arbitrary-query *` for authenticated callers, but that secondary effect does not grant new permissions.\n\n### Impact\n\n`SURREAL_WEBSOCKET_MAX_MESSAGE_SIZE` is not applied to anonymous `/sql` connections, so each connection can buffer up to the WebSocket library defaults (16 MiB per frame, 64 MiB per reassembled message) of in-flight bytes regardless of the operator's configured limit. Holding this much memory pinned requires actively streaming bytes into the connection, so an attacker has to maintain bandwidth across many concurrent connections to consume meaningful memory. Within that constraint the result is degraded availability for legitimate `/sql` clients; on memory-constrained deployments the process may be OOM-killed and restarted during the attack rather than denied service outright.\n\nSeparately, `--deny-http sql` and `--deny-arbitrary-query *` were not enforced on the WebSocket, so SurrealQL operations the operator had configured to refuse could still be issued by any authenticated principal that already held the corresponding data permissions. This is a configuration-correctness defect — the bypass does not grant new permissions.\n\n### Patches\n\nA patch has been introduced that performs the two capability checks before calling `on_upgrade` and applies the same per-connection size limits used by `/rpc`. The capability checks enforce the operator's configured deny flags; they do not change what any authenticated principal is permitted to do.\n\n- Versions 3.1.0 and later are not affected by this issue.\n\n### Workarounds\n\nAffected users who are unable to update should refuse `GET /sql` requests carrying `Upgrade: websocket` at a reverse proxy, or apply per-connection frame size limits at the reverse proxy.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "surrealdb"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "3.1.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-65rj-r9fh-jp2v"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/surrealdb/surrealdb/commit/899967e6a9cf064c88a4bc4b35ea7e2da28a6411"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/surrealdb/surrealdb"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-770" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-01T20:15:03Z",
    "nvd_published_at" : null
  }
}