CVE-2026-109338 in SurrealDB
Summary
by MITRE • 10/12/2026
SurrealDB before 3.3.0 contains a denial of service vulnerability that allows query-capable users to crash the server by reading non-ASCII header values in embedded JavaScript. Attackers with scripting enabled can read such values via Headers get(), entries(), values(), or getSetCookie(), or return them from fetch() endpoints, aborting the server process.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in SurrealDB versions prior to 3.3.0 represents a critical denial of service flaw rooted in improper handling of character encoding within embedded JavaScript environments. This issue specifically affects systems where scripting capabilities are enabled and allows authenticated users with query permissions to trigger server crashes through the manipulation of HTTP header values. The core technical failure lies in the processing logic for non-ASCII characters found within these headers when they interact with the internal JavaScript engine used by the database system. When a user attempts to read or manipulate header data using methods such as Headers get(), entries(), values(), or getSetCookie(), or when returning data from fetch() endpoints, the application fails to correctly validate or sanitize non-ASCII byte sequences. This lack of robust input validation leads to an internal error state that is not gracefully handled by the server process, resulting in a fatal exception and subsequent termination of the SurrealDB instance.
From a technical perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the system does not adequately restrict or sanitize inputs containing non-standard character sets before processing them within the embedded runtime environment. The attack vector is classified under ATT&CK technique T1499 Endpoint Denial of Service, specifically leveraging resource exhaustion through application crash rather than traditional CPU or memory flooding techniques. Because the vulnerability requires query-capable users to exploit it, the threat model assumes that an attacker has already gained some level of access to the database interface but lacks full administrative privileges. This distinction is crucial for risk assessment, as it limits the scope of potential attackers compared to unauthenticated remote code execution vulnerabilities, yet still poses a significant operational risk due to the ease with which service availability can be disrupted.
The operational impact of this vulnerability is severe in terms of system reliability and continuity of operations. A successful exploit results in an immediate crash of the SurrealDB server process, leading to a complete outage for all connected clients until the service is manually restarted or automatically recovered by external monitoring systems. In production environments where high availability is required, such crashes can cause data inconsistency if transactions are interrupted mid-execution and disrupt dependent services that rely on continuous database connectivity. Furthermore, repeated exploitation attempts could be used as part of a broader campaign to degrade system performance or distract security teams while other malicious activities occur elsewhere in the infrastructure. The ability for users with scripting enabled to trigger this crash means that any application layer utilizing SurrealDB with dynamic query generation is potentially vulnerable if it does not strictly control which characters are passed into header-related JavaScript functions.
Mitigation strategies must focus on both immediate patching and architectural hardening. The primary remediation step is to upgrade the SurrealDB instance to version 3.3.0 or later, where this input validation flaw has been addressed by developers through improved encoding handling in the embedded JavaScript context. For environments where upgrading is not immediately feasible, administrators should consider disabling scripting capabilities if they are not strictly required for application functionality, thereby removing the attack surface entirely. Additionally, implementing a reverse proxy or API gateway with strict header sanitization rules can help filter out non-ASCII characters before they reach the database layer. Monitoring tools should be configured to detect sudden process terminations of SurrealDB instances, enabling rapid incident response and recovery procedures to minimize downtime during exploitation attempts.