Listen to this Post
How the CVE Works
The `KILL` statement in SurrealDB is designed to terminate active `LIVE SELECT` subscriptions that stream real‑time table changes to clients. Its implementation resides in core/src/expr/statements/kill.rs. When a `KILL` command is issued, the server first performs a `valid_for_db()` check to confirm that the authenticated user has at least database‑level access. This check passes for any user who holds permissions on the target database.
After this superficial validation, the statement resolves the provided UUID, looks up the corresponding live query entry in the server’s internal registry, and immediately deletes it. Critically, the code does not compare the identity of the requesting user against the `owner` field stored with the live query. As a result, any authenticated user with database access can terminate any live query running in that database, regardless of who originally started it.
The victim receives no notification that their subscription has been killed; their real‑time stream simply stops delivering updates without error or warning. The attack is effective across privilege boundaries—a low‑privilege record‑scoped user can, for example, terminate a root user’s monitoring live queries, undermining multi‑tenant isolation.
The vulnerability was discovered during a code audit and penetration test performed by Cure53. Cure53 assigned a preliminary severity of Medium, and SurrealDB’s own CVSS v3.1 assessment confirms this rating. The fix introduces an ownership verification step that checks the requester’s authentication context against the live query’s owner before allowing deletion. All versions 3.1.0 and later include this patch.
DailyCVE Form
| Field | Value |
|-|-|
| Platform | SurrealDB |
| Version | < 3.1.0 |
| Vulnerability | Authorization Bypass |
| Severity | Medium |
| Date | 2025‑04‑10 |
| Prediction | 2025‑04‑10 |
What Undercode Say
Analytics – Bash Commands & Code Snippets
1. Start a live query (as user 'alice') surreal sql --ns test --db app --user alice --pass alice123 \ "LIVE SELECT FROM users;" Returns a UUID, e.g., '123e4567-e89b-12d3-a456-426614174000' 2. Attacker 'bob' (same database, different user) kills Alice's live query surreal sql --ns test --db app --user bob --pass bob123 \ "KILL 123e4567-e89b-12d3-a456-426614174000;" Succeeds – no ownership check, Alice's stream stops silently
Rust snippet showing the missing check (pre‑patch):
// core/src/expr/statements/kill.rs (vulnerable)
fn process_kill(ctx: &Context, uuid: Uuid) -> Result<()> {
// Only verifies database-level access
ctx.valid_for_db()?;
// Directly deletes the live query without ownership verification
ctx.kill_live_query(uuid)?;
Ok(())
}
Post‑patch verification (added in 3.1.0):
fn process_kill(ctx: &Context, uuid: Uuid) -> Result<()> {
ctx.valid_for_db()?;
let live = ctx.get_live_query(uuid)?;
// Enforce ownership
if live.owner != ctx.auth_context().user_id() {
return Err(Error::PermissionDenied);
}
ctx.kill_live_query(uuid)?;
Ok(())
}
Exploit
An attacker must satisfy two conditions:
- Authenticated – have any valid user account with database‑level access.
- Knowledge of the target live query UUID – these are randomly generated, but can be exposed through:
– Application logs that inadvertently log query IDs.
– Shared monitoring dashboards.
– Error messages that leak the UUID.
– Information disclosure from other vulnerabilities.
Once the UUID is known, the attacker simply issues a `KILL
Protection
- Upgrade to SurrealDB version 3.1.0 or later – the official patch introduces the ownership verification check.
- Treat live query UUIDs as sensitive – avoid logging them, exposing them in error messages, or sharing them through any interface accessible to other users.
- Use separate databases per tenant when multi‑tenant isolation is critical; do not rely solely on record‑level permissions within a shared database.
- Implement application‑level resilience – monitor for unexpected live‑query termination and include automatic reconnection and re‑subscription logic to recover from silent kills.
Impact
- Availability – an attacker can silently disrupt any real‑time data subscription, affecting dashboards, monitoring, and reactive application logic.
- Multi‑tenant isolation breach – a low‑privileged user can terminate queries owned by higher‑privileged users, undermining the security model of co‑tenanted applications.
- No audit trail – the victim receives no notification, making detection and incident response difficult.
- Wide attack surface – any authenticated user with database access is a potential threat, and UUID leakage (through logs, etc.) is the only prerequisite.
🎯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
