GHSA-FPXG-5XMV-922M

Vulnerability from github – Published: 2026-07-01 20:18 – Updated: 2026-07-01 20:18
VLAI
Summary
SurrealDB has bypass of field-level SELECT permissions through JSON Patch `copy` and `move` with empty `from`
Details

SurrealDB lets callers modify records using JSON Patch operations via the UPDATE … PATCH statement (and SDK equivalents such as db.patch()). One of those operations is copy, which duplicates one field's value into another field of the same record. A PATCH with an empty from — for example, UPDATE thing:1 PATCH [{ op: 'copy', from: '', path: '/leak' }] — was treated as "copy the entire record" and duplicated every field, including fields the caller has no permission to read, into the destination field the caller chose. The permission filter that hides protected field values from the response only knew to hide the original protected field names, not the new destinations, so the protected values were returned to the caller intact under the new field name.

Impact

An authenticated user with permission to issue UPDATE … PATCH against a record could read the values of any field on that record, regardless of field-level PERMISSIONS FOR select restrictions. The leak is confidentiality-only, and bounded to the fields of the single record the caller targets per PATCH request — it does not expose other records on the same table or any data outside that record's scope.

Patches

A patch has been introduced that rejects an empty from pointer at parse time for both copy and move operations.

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

Workarounds

Affected users who are unable to update should restrict UPDATE … PATCH to callers who already hold SELECT permission on every field of the target record — for them, the bug exposes nothing they can't already read. Otherwise, switch the mutation to an explicit SET or MERGE clause, which removes the attack surface since neither form accepts JSON Patch operations.

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-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T20:18:06Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "SurrealDB lets callers modify records using JSON Patch operations via the `UPDATE \u2026 PATCH` statement (and SDK equivalents such as `db.patch()`). One of those operations is `copy`, which duplicates one field\u0027s value into another field of the same record. A `PATCH` with an empty `from` \u2014 for example, `UPDATE thing:1 PATCH [{ op: \u0027copy\u0027, from: \u0027\u0027, path: \u0027/leak\u0027 }]` \u2014 was treated as \"copy the entire record\" and duplicated every field, including fields the caller has no permission to read, into the destination field the caller chose. The permission filter that hides protected field values from the response only knew to hide the *original* protected field names, not the new destinations, so the protected values were returned to the caller intact under the new field name.\n\n### Impact\n\nAn authenticated user with permission to issue `UPDATE \u2026 PATCH` against a record could read the values of any field on that record, regardless of field-level `PERMISSIONS FOR select` restrictions. The leak is confidentiality-only, and bounded to the fields of the single record the caller targets per PATCH request \u2014 it does not expose other records on the same table or any data outside that record\u0027s scope.\n\n### Patches\n\nA patch has been introduced that rejects an empty `from` pointer at parse time for both `copy` and `move` operations.\n\n- Versions 3.1.0 and later are not affected by this issue.\n\n### Workarounds\n\nAffected users who are unable to update should restrict `UPDATE \u2026 PATCH` to callers who already hold SELECT permission on every field of the target record \u2014 for them, the bug exposes nothing they can\u0027t already read. Otherwise, switch the mutation to an explicit `SET` or `MERGE` clause, which removes the attack surface since neither form accepts JSON Patch operations.",
  "id": "GHSA-fpxg-5xmv-922m",
  "modified": "2026-07-01T20:18:06Z",
  "published": "2026-07-01T20:18:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-fpxg-5xmv-922m"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/commit/56a7a1540d9228f82fd6284c258344e8dcb690fd"
    },
    {
      "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:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SurrealDB has bypass of field-level SELECT permissions through JSON Patch `copy` and `move` with empty `from`"
}



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…