GHSA-GCWR-5MRF-FVCH

Vulnerability from github – Published: 2026-07-01 20:14 – Updated: 2026-07-01 20:14
VLAI
Summary
SurrealDB: Authorization Bypass in KILL Statement Allows Termination of Other Users' Live Queries
Details

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.

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.

Patches

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.

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.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T20:14:20Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "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.\n \nAfter 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\u0027s 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.\n \nThe affected user\u0027s 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\u0027s monitoring live queries.\n \nThis issue was discovered and patched during a code audit and penetration test of SurrealDB by cure53, the severity defined within cure53\u0027s preliminary finding is Medium, matched by our CVSS v3.1 assessment.\n \n### Impact\n \nAn authenticated user with database-level access can terminate any other user\u0027s live query subscriptions within the same database by issuing a `KILL` statement with the target live query\u0027s UUID. This impacts availability by silently disrupting real-time data subscriptions and breaks multi-tenant isolation guarantees.\n \nThe 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.\n \n### Patches\n \nAn ownership verification check has been introduced in the `KILL` statement implementation that compares the requesting user\u0027s authentication context against the owner of the live query before allowing deletion.\n \n- Versions 3.1.0 and later are not affected by this issue.\n \n### Workarounds\n \nUsers unable to upgrade should consider the following mitigations:\n \n- 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.\n- Where multi-tenant isolation is critical, use separate databases per tenant rather than relying on record-level access controls within a shared database.\n- Monitor for unexpected termination of live queries in application logic and implement reconnection and re-subscription mechanisms.",
  "id": "GHSA-gcwr-5mrf-fvch",
  "modified": "2026-07-01T20:14:20Z",
  "published": "2026-07-01T20:14:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-gcwr-5mrf-fvch"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/commit/36f0a41a69b551172c7d1d13b1e8dbbd868e2ead"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/surrealdb/surrealdb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SurrealDB: Authorization Bypass in KILL Statement Allows Termination of Other Users\u0027 Live Queries"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…