6.5

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

GHSA-4v76-cw68-4vc9

GHSA-4v76-cw68-4vc9: SurrealDB: Crafting malicious LIVE queries writes to the database, resulting in DoS, without permission to the table required

A LIVE query whose WHERE clause evaluates to an error caused the source data modifier (the user creating, updating, or deleting a record on the watched table) to fail instead. Calling any arbitrary SurrealQL function with a typed parameter and passing a value of the wrong type — for example LIVE SELECT * FROM t WHERE string::trim(deny) — triggered an evaluation error inside the LIVE notification path. That error then propagated through to the triggering write, rolling back the attempted change.

While such a LIVE query was registered, all CREATE, UPDATE, and DELETE operations on the watched table failed — including those issued by a root user — for as long as the registration remained active. Registering the LIVE required select permission on the table; no other permission on the table was needed.

Impact

An authenticated user with select permission on a table can prevent all CREATE, UPDATE, and DELETE operations on that table — by any other user, up to and including root — for the lifetime of a single registered LIVE query. Service is restored when the LIVE query is killed or the session that registered it ends.

Patches

A patch has been introduced that:

Decouples LIVE query evaluation errors from the source transaction — when lq_check returns an error during the LIVE notification path, the error is now reported to the LIVE subscriber as an Action::Error notification and the LIVE processing path returns Ok(()). The triggering write proceeds normally.
Defers the error notification until after the permission check — the Action::Error notification is only delivered after the LIVE subscription's PERMISSIONS clause has been evaluated, so unauthorised subscribers do not learn even that an error occurred (closing an information-disclosure side channel introduced by the first part of the fix).

Versions 3.1.0 and later are not affected by this issue.

Workarounds

Users unable to upgrade should restrict the ability of untrusted users to register LIVE queries by removing the select permission on tables they want to keep writeable, or by gating LIVE registration at the application layer.

(GitHub Advisory)

Miggo Vulnerability Database

→

GHSA-4v76-cw68-4vc9

GHSA-4v76-cw68-4vc9:

6.5

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
surrealdb	rust	< 3.1.0	3.1.0

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability allows a user with select permissions to cause a Denial of Service (DoS) on a table, preventing any CREATE, UPDATE, or DELETE operations. This is achieved by registering a LIVE query with a malicious WHERE clause that is designed to always fail during evaluation.

The root cause of the vulnerability was in the error handling within the LIVE query notification process. When a write operation triggered a notification for the malicious LIVE query, the surrealdb::core::doc::lives::Document::lq_check function would evaluate the WHERE clause. The evaluation would fail as intended by the attacker, and lq_check would return an error.

The critical flaw was in the calling function, surrealdb::core::doc::lives::Document::notify. Before the patch, this function would propagate the error up the call stack. This error propagation was not contained within the LIVE query processing logic and would instead cause the entire parent database transaction for the write operation to be aborted and rolled back.

The fix, implemented in commit b29e03f0714d1c4ec091fc6f27f1edbe243b8aec, was to change the behavior of the notify function. It now catches the error from lq_check, sends an Action::Error notification to the subscriber of the LIVE query, and then returns Ok(()). This decouples the LIVE query evaluation from the write transaction, allowing the write to succeed even if the LIVE query evaluation fails, thus mitigating the DoS vulnerability. A further hardening was also added to surrealdb::core::expr::statements::live::LiveStatement::analyse to reject some invalid queries at registration time.

Vulnerable functions

surrealdb::core::doc::lives::Document::notify

surrealdb/core/src/doc/lives.rs

This function was responsible for handling notifications for `LIVE` queries. Before the patch, if a `LIVE` query's `WHERE` clause evaluation resulted in an error, this function would propagate the error, causing the database write operation that triggered the notification to be aborted. This allowed a user with `select` permissions to create a malicious `LIVE` query that would cause a Denial of Service for all write operations on a table.

surrealdb::core::doc::lives::Document::lq_check

surrealdb/core/src/doc/lives.rs

This function is responsible for evaluating the `WHERE` clause of a `LIVE` query. It processes the potentially malicious input from the user. When a crafted `WHERE` clause caused an evaluation error, this function would return an error that was improperly handled by its caller, leading to a Denial of Service.

surrealdb::core::expr::statements::live::LiveStatement::analyse

surrealdb/core/src/expr/statements/live.rs

This function analyzes and registers `LIVE` queries. Prior to the patch, it would allow the registration of queries with `WHERE` clauses that were guaranteed to fail, without performing any validation. This allowed the malicious query to enter the system. The patch adds a check to prevent this for a class of simple invalid queries.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.