# GHSA-65rj-r9fh-jp2v: SurrealDB vulnerable to pre-auth memory amplification via unbounded `/sql` WebSocket frames

> Anonymous attackers can exhaust memory via oversized WebSocket frames, causing denial of service in SurrealDB deployments.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 1 Jul 2026

## What is GHSA-65rj-r9fh-jp2v?

GHSA-65rj-r9fh-jp2v is a denial of service vulnerability in surrealdb, published on 1 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

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.

## Which versions are affected by GHSA-65rj-r9fh-jp2v?

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


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

## How do I fix GHSA-65rj-r9fh-jp2v?

Upgrade surrealdb to 3.1.0 or later.

## Is GHSA-65rj-r9fh-jp2v being exploited?

There is no known exploitation of GHSA-65rj-r9fh-jp2v in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-65rj-r9fh-jp2v and fix it if it is affected.

What it is: GHSA-65rj-r9fh-jp2v is a denial of service vulnerability in surrealdb, published on 1 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-65rj-r9fh-jp2v in the wild and no public exploit code.

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

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-65rj-r9fh-jp2v/ (Markdown: https://insights.sbomify.com/GHSA-65rj-r9fh-jp2v/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-65rj-r9fh-jp2v

---
From sbomify Insights: https://insights.sbomify.com/GHSA-65rj-r9fh-jp2v/
Summaries are generated and may contain mistakes; the official description above is the record.