https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 11:52:56 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-341473 EUVD-2026-341473 https://cve.radiocsirt.org/vuln/euvd-2026-341473 https://cve.radiocsirt.org/vuln/fkie_cve-2026-63738 <p>SurrealDB versions 3.1.0 before 3.1.5 fail to enforce field-level SELECT permissions when records are accessed through graph-edge or back-reference traversals. Attackers with table-level SELECT access can read field values hidden by field-level permissions by materializing records through graph traversals instead of direct table scans.</p> <p>SurrealDB versions 3.1.0 before 3.1.5 fail to enforce field-level SELECT permissions when records are accessed through graph-edge or back-reference traversals. Attackers with table-level SELECT access can read field values hidden by field-level permissions by materializing records through graph traversals instead of direct table scans.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-63738 https://cve.radiocsirt.org/vuln/ghsa-hv6h-hc26-q48p <p><strong>Affected:</strong> crates.io: surrealdb</p> <p>A record user could read field values hidden from them by field-level SELECT permissions by reaching the records through a graph-edge (`-&gt;`) or back-reference (`&lt;~`) traversal instead of a direct `SELECT`.</p> <p>When a table was readable at the table level but carried a field hidden by a field-level permission (`DEFINE FIELD secret ON knows PERMISSIONS FOR select NONE`), a direct `SELECT * FROM knows` hid `secret` — but reaching the same records through a traversal that yields full objects — `person:bob-&gt;(SELECT * FROM knows)`, `person:bob&lt;~(SELECT * FROM comment)`, or a projected target vertex `-&gt;knows-&gt;(SELECT * FROM person)` — returned it intact.</p> <p>The root cause: the shared `resolve_record_batch` helper used by `GraphEdgeScan` (`FullEdge`) and `ReferenceScan` (`FullRecord`) enforced only the table-level SELECT permission and pushed raw record data, never running the field-level filtering (`build_field_state` / `filter_fields_by_permission`) that ordinary table scans and `fetch_record` apply.</p> <p>### Impact</p> <p>A record user can read the values of fields hidden by field-level SELECT permissions, on tables they already hold table-level SELECT on, by materialising the records through a graph-edge, back-reference, or target-vertex traversal — recovering the values directly, for every record the traversal returns.</p> <p>The disclosure is confined to the field-permission layer: it grants **no unauthorised cross-table, cross-record, or cross-namespace/database access**. The table&#39;s own SELECT p…</p> <p><strong>Affected:</strong> crates.io: surrealdb</p> <p>A record user could read field values hidden from them by field-level SELECT permissions by reaching the records through a graph-edge (`-&gt;`) or back-reference (`&lt;~`) traversal instead of a direct `SELECT`.</p> <p>When a table was readable at the table level but carried a field hidden by a field-level permission (`DEFINE FIELD secret ON knows PERMISSIONS FOR select NONE`), a direct `SELECT * FROM knows` hid `secret` — but reaching the same records through a traversal that yields full objects — `person:bob-&gt;(SELECT * FROM knows)`, `person:bob&lt;~(SELECT * FROM comment)`, or a projected target vertex `-&gt;knows-&gt;(SELECT * FROM person)` — returned it intact.</p> <p>The root cause: the shared `resolve_record_batch` helper used by `GraphEdgeScan` (`FullEdge`) and `ReferenceScan` (`FullRecord`) enforced only the table-level SELECT permission and pushed raw record data, never running the field-level filtering (`build_field_state` / `filter_fields_by_permission`) that ordinary table scans and `fetch_record` apply.</p> <p>### Impact</p> <p>A record user can read the values of fields hidden by field-level SELECT permissions, on tables they already hold table-level SELECT on, by materialising the records through a graph-edge, back-reference, or target-vertex traversal — recovering the values directly, for every record the traversal returns.</p> <p>The disclosure is confined to the field-permission layer: it grants **no unauthorised cross-table, cross-record, or cross-namespace/database access**. The table&#39;s own SELECT p…</p> https://cve.radiocsirt.org/vuln/ghsa-hv6h-hc26-q48p