SurrealDB's Poison Pill: Crashing the Database with a Single String

SurrealDB is the Swiss Army knife of modern databases. It wants to be everything: a document store, a graph database, and a relational powerhouse. To achieve this flexibility, it allows developers to write custom logic not just in its native SurrealQL, but also in JavaScript.

To make this happen without dragging in the massive footprint of V8 (Node.js), SurrealDB embeds QuickJS, a lightweight JavaScript engine written in C. This is where things get spicy. While SurrealDB is written in Rust—a language famous for its memory safety guarantees—it has to interface with QuickJS via Foreign Function Interfaces (FFI).

When you cross the border from Rust (Safe) to C (Unsafe), you leave your armor behind. If the C code decides to dereference a null pointer because it ran out of memory or got confused by a massive literal, Rust can't catch the panic. The operating system steps in, sees a segmentation fault, and kills the process instantly. No error log, no graceful shutdown. Just silence.

The vulnerability lies deep within the compilation phase of QuickJS (specifically versions prior to the patch included in rquickjs 0.11.0). When the engine parses source code, it has to allocate memory for string literals (constants) found in the script.

Here is the sequence of doom:

1. The user provides a script containing a string literal of astronomical size.
2. QuickJS attempts to "atomize" this string—converting it into an internal unique identifier.
3. Due to the size, the internal allocation logic hits an edge case. It might fail to allocate memory, or it might encounter an integer overflow in the size calculation.
4. Instead of returning an error that propagates up the stack, a function deeper in the parser returns a NULL pointer (or an invalid state representing one).
5. The compiler, assuming the atomization succeeded, attempts to read from this pointer.

CWE-476 (Null Pointer Dereference) triggers. In a pure C environment, this is a crash. Because QuickJS is running inside the main SurrealDB thread (or a worker thread that shares the process), the OS sends SIGSEGV, and the database vanishes.

This vulnerability highlights a classic supply chain risk. SurrealDB's code didn't technically have a logic bug; its dependency did. The fix wasn't a change to the query parser, but a bump in the rquickjs crate, which wraps QuickJS for Rust.

The vulnerable code relied on rquickjs versions < 0.11.0. The patch is simple in implementation but critical in impact.

The Vulnerable State (Abstracted):

// Cargo.toml
[dependencies]
rquickjs = { version = "0.6", features = ["full"] }
// This pulls in an older, vulnerable C-based QuickJS

The Fix (Commit bcd2ece):

// Cargo.toml
[dependencies]
// Updating to 0.11.0 brings in QuickJS-NG v0.9
// which includes hardened memory checks.
rquickjs = { version = "0.11.0", features = ["full"] }

The fix is invisible to the end user's logic, but binary-wise, it replaces the engine with one that actually checks if malloc returned NULL before writing to it.

Exploiting this is trivially easy if you have permissions to define functions. We don't even need to send a 1GB payload over the network; we can ask SurrealDB to generate the poison pill for us using string::repeat.

The attack vector looks like this:

1. Generate the Payload: We create a variable $bomb containing a massive string.
2. Inject and Compile: We embed this string into a JavaScript function definition. The moment SurrealDB tries to parse this function to store it (or execute it), QuickJS chokes.

Proof of Concept (SurrealQL):

-- Step 1: Create a massive string in memory (SurrealDB handles this fine initially)
LET $payload = string::repeat("A", 50000000); 
 
-- Step 2: Define a JS function that includes this string as a literal
-- The mere act of parsing this script triggers the NPD in QuickJS
DEFINE FUNCTION fn::crash_me() {
    return "" + $payload + "";
};

When the server processes the DEFINE FUNCTION statement, it passes the body to rquickjs to compile bytecode. The compiler sees the massive string literal, fails the allocation check, dereferences NULL, and the server crashes.

This is a high-availability nightmare.

Availability: Total loss. The crash is not a caught exception; it is a process termination. If you are running a single instance of SurrealDB, your application goes offline immediately. If you are running a cluster, a persistent attacker could crash nodes sequentially or simultaneously.

Privilege Requirement: Low. Any user who can define functions or execute ad-hoc scripts can trigger this. in many configurations, this might be a standard application user.

Data Integrity: Paradoxically safe. Because the process dies so abruptly, it's unlikely to corrupt data on disk (thanks to RocksDB/TiKV transactional guarantees), but any in-flight transactions are lost.

If you are running SurrealDB, you have two options. One is a fix, the other is a workaround.

1. The Patch: Upgrade to the latest version of SurrealDB (post-February 2026 builds). Ensure the release notes mention the rquickjs update to 0.11.0 or higher.

2. The Workaround: If you cannot upgrade, you must disable the scripting capability. This removes the attack surface entirely by preventing the QuickJS engine from being invoked.

Start your server with scripting disabled if your application logic allows it:

surreal start --deny-scripting

> [!NOTE] > Relying on embedded scripting engines for core database logic is always a double-edged sword. It offers power, but imports the vulnerabilities of the scripting language into your database kernel.