Summary
The KILL statement is used to terminate LIVE SELECT subscriptions that capture real-time changes to data within a table. The KILL statement implementation in core/src/expr/statements/kill.rs verifies that the requesting user has database-level access, but does not verify that the requesting user is the owner of the live query being terminated.
After passing the valid_for_db() check, the KILL statement resolves the live query UUID, looks up the corresponding live query entry, and immediately deletes it without comparing the requesting user's identity against the live query owner. This allows any authenticated user with database-level access to terminate any live query in that database, regardless of who created it.
The affected user's real-time subscription silently stops receiving updates with no notification that the live query was terminated. The same attack works across privilege levels: a low-privilege record-scoped user can terminate a root user's monitoring live queries.
This issue was discovered and patched during a code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Medium, matched by our CVSS v3.1 assessment.
Workarounds
Users unable to upgrade should consider the following mitigations:
- Ensure that live query UUIDs are treated as sensitive values and are not exposed to other users through application logs, error messages, or shared interfaces.
- Where multi-tenant isolation is critical, use separate databases per tenant rather than relying on record-level access controls within a shared database.
- Monitor for unexpected termination of live queries in application logic and implement reconnection and re-subscription mechanisms.
Impact
An authenticated user with database-level access can terminate any other user's live query subscriptions within the same database by issuing a KILL statement with the target live query's UUID. This impacts availability by silently disrupting real-time data subscriptions and breaks multi-tenant isolation guarantees.
The attack requires knowledge of the target live query UUID. Live query UUIDs are randomly generated, but may be exposed through application logs, shared monitoring dashboards, or other information disclosure vectors.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
GHSA-GCWR-5MRF-FVCH has a CVSS score of 5.4 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.1.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
An ownership verification check has been introduced in the KILL statement implementation that compares the requesting user's authentication context against the owner of the live query before allowing deletion.
- Versions 3.1.0 and later are not affected by this issue.
Frequently Asked Questions
- What is GHSA-GCWR-5MRF-FVCH? GHSA-GCWR-5MRF-FVCH is a medium-severity missing authorization vulnerability in surrealdb (rust), affecting versions < 3.1.0. It is fixed in 3.1.0. The application does not perform an authorization check before performing a sensitive operation.
- How severe is GHSA-GCWR-5MRF-FVCH? GHSA-GCWR-5MRF-FVCH has a CVSS score of 5.4 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of surrealdb are affected by GHSA-GCWR-5MRF-FVCH? surrealdb (rust) versions < 3.1.0 is affected.
- Is there a fix for GHSA-GCWR-5MRF-FVCH? Yes. GHSA-GCWR-5MRF-FVCH is fixed in 3.1.0. Upgrade to this version or later.
- Is GHSA-GCWR-5MRF-FVCH exploitable, and should I be worried? Whether GHSA-GCWR-5MRF-FVCH is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-GCWR-5MRF-FVCH is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-GCWR-5MRF-FVCH? Upgrade
surrealdbto 3.1.0 or later.