CVE-2026-109341 is a high severity authorization bypass (CVSS 7.1) in SurrealDB. Users with table-level write permission can read fields hidden by a SELECT permission rule, by using JSON Patch copy, move or test operations. SurrealDB 3.3.0 is the fixed version.
What's affected
The record says SurrealDB before 3.3.0 is affected. The GitHub advisory GHSA-h2c3-549c-gjpr, published on 28 September 2026 and rated High, lists the Cargo package surrealdb with affected versions below 3.3.0 and a patched version of 3.3.0. The sources agree.
The weakness is CWE-200, exposure of sensitive information to an unauthorised actor. The vector is network reachable, low complexity, low privileges, no interaction, high confidentiality impact and low integrity impact.
The advisory scopes the exposure. It affects deployments that use field level permissions on select to hide fields from users who still hold table level write permission, for example multi tenant tables, user profile tables, or partial redaction where record users can update rows. The write operations named are UPDATE, CREATE, UPSERT, RELATE and INSERT.
If your database does not combine hidden fields with writable tables for the same users, you are not in the pattern the advisory describes.
How to check if you're exposed
Check the database version:
surreal version
Anything below 3.3.0 needs the upgrade. For an embedded SurrealDB in a Rust application, check your lockfile:
cargo tree -i surrealdb
Then review your schema for the risky combination. Look for field definitions with a select permission of none or a condition, on tables where record users also have update or create permission. Export your schema and read the DEFINE FIELD and DEFINE TABLE statements:
surreal export --conn http://localhost:8000 --ns YOUR_NS --db YOUR_DB schema.surql
Supply credentials as your setup requires. Mark every table where hidden fields exist and ordinary users can write.
What to do now
- Upgrade SurrealDB to 3.3.0 or later and test your permission rules after the upgrade.
- Review every table that hides fields with a select permission and also lets record users write.
- Assume values in hidden fields may have been read by users with write access, and rotate any secret you stored in such a field.
- Where possible, move truly secret values to a separate table that record users cannot write to.
- Add a test to your suite that tries to read a hidden field through every write path and fails if the value appears.
Why it matters
Database permissions come in layers: who may write a row and who may read each field. The bug came from two code paths that treated the layers differently. For the common ways of writing data, the right hand side is computed against a view of the record from which hidden fields have been removed, so a restricted field reads as empty. The advisory says the PATCH operation was the exception: it worked on the full record, so a copy or move from a hidden field resolved to the real value.
That let a user copy a secret into a field they could read. The test operation was a smaller leak: a failed test returned an error that included the value it found. The advisory notes that a previous fix had covered part of the same area, so the lesson is to test every write path, not one.
The score reflects a confidentiality problem for authenticated users, not an anonymous one. The record does not mark this CVE as known exploited.
Try it yourself
See how this kind of finding shows up in a dependency workflow.
Click through it at your own pace, or open it full screen.
Quick check
Do I need to act if my hidden fields are on read only tables?
The advisory describes users who also hold table level write permission. Upgrading is still the clean answer.
Could the data have been read already?
The advisory does not say. If you stored secrets in hidden fields on writable tables, treat them as possibly exposed.
Sources
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your packages carry known CVEs.
Last reviewed: 18 October 2026.
