Vulnerability Database

362,557

Total vulnerabilities in the database

SurrealDB: Scraping a TABLE with no available PERMISSIONS to current auth level — surrealdb

Incorrect Authorization

A vulnerability was discovered where the user-supplied WHERE clause in a SELECT statement is evaluated against the full record data before PERMISSIONS FOR SELECT WHERE determines whether the principal is authorised to access that record. A side-effecting expression in the WHERE clause can exfiltrate record contents before the permission check runs. The same ordering bug affects the SET, MERGE, CONTENT and PATCH clauses of update-variant statements (UPDATE, UPSERT-update, INSERT ON DUPLICATE KEY UPDATE, RELATE-update).

This vulnerability is confined to the attacker's current database. It does not cross namespace or database isolation boundaries.

Impact

An authenticated user — including Record and Scope users — can read the full contents of any table in the database they are authenticated against, bypassing PERMISSIONS FOR SELECT WHERE restrictions on those tables.

The most direct exfiltration method requires scripting functions to be enabled (--allow-scripting / -A). However, exfiltration via SurrealQL's THROW statement is also feasible without scripting functions, and timing-based side-channel extraction is possible in all configurations.

All tables within the attacker's current database, regardless of table-level PERMISSIONS FOR SELECT WHERE restrictions on those tables, are vulnerable to this attack. Tables in other databases within the same namespace, or within other namespaces, are not vulnerable.

Patches

A patch has been introduced that runs check_permissions_table before any user-supplied expression is evaluated against the record. A new check_pre_update helper centralises this ordering on every update-variant code path. Regression tests covering WHERE, SET, MERGE, CONTENT, INSERT ON DUPLICATE KEY UPDATE, and RELATE with THROW side-effects are included.

  • Versions 3.1.0 and later are not affected by this issue.

Workarounds

Affected users who are unable to update may want to:

  • Disable scripting functions if not required — remove the -A / --allow-scripting flag. This blocks the most direct exfiltration method but does not fully mitigate the vulnerability, as THROW-based and timing-based exfiltration remain possible.
  • Limit query access — restrict the ability of untrusted principals to run arbitrary SELECT queries with user-controlled WHERE clauses.
  • Use namespace/database isolation instead of table-level permissions as the primary security boundary where feasible, since the vulnerability is in table-level permission enforcement, not namespace or database isolation.
  • Published: Jul 1, 2026
  • Updated: Jul 2, 2026
  • GHSA: GHSA-98fx-66cf-fc7c
  • Severity: Medium
  • Exploit:
  • CISA KEV:

CVSS v3:

  • Severity: Medium
  • Score: 6.5
  • AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

CWEs:

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.