Security Feed

A record user could read records the table's SELECT permission expression should have hidden, when that expression referenced `$value`, `$before`, `$after`, or `$event`. Binding a chosen value to that name before registering a `LIVE SELECT` caused notifications to evaluate the permission against the attacker's input instead of the real document. ### Impact A record user binds a value to `$value`, `$before`, `$after`, or `$event` (e.g. `LET $value = [$auth.id]`) and registers `LIVE SELECT * FRO

`RELATE` creates an edge record between two existing records, and SurrealDB enforces the `CREATE` permission on the edge table for this operation. When the statement included a `SET id = edge:existing` clause, however, the new edge's id ended up pointing at an record that was already in storage. Rather than failing because the target already existed — which is what a create operation should do — the storage layer silently overwrote the existing edge. A caller with `CREATE` permission could there

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 d

In Vinyl Cache before 9.0.1 and Varnish Cache before 9.0.3, a deficiency in HTTP/2 request parsing can be exploited to launch a backend request desync attack (request smuggling), which in turn can be used for cache poisoning, authentication bypass, or possibly even information disclosure and manipulation. The attack vector only exists if HTTP/2 support is enabled by setting the feature parameter to contain +http2. HTTP/2 support is disabled by default.

Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. Prior to 10.9.6 and 11.15.0, Mermaid's default configuration allows injecting CSS that applies outside of the Mermaid diagram via the fontFamily, themeCSS, and altFontFamily configuration options. The injected CSS exploits stylis's & (scope reference) handling. :not(&) escapes the #mermaid-xxx automatic scoping, applying styles to all page elements. Global at-rules (@font-face, @keyframes, @c

Uninitialized Use in ANGLE in Google Chrome on Mac prior to 150.0.7871.47 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: High)

Use after free in GPU in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)

Overly permissive file permissions in AWS CLI before 1.44.78 (v1) and 2.34.29 (v2) on Unix-like systems where the umask has not been configured to restrict file permissions (the default on most systems) may allow other local users on the same host to read credentials written by certain CLI subcommands (aws codeartifact login, aws iam create-virtual-mfa-device, aws deploy register). To remediate this issue, users should upgrade to AWS CLI 1.44.78 (v1) or 2.34.29 (v2) or later.

OS command injection in the NodejsFunction Docker bundling pipeline (OsCommand helper) in AWS aws-cdk-lib on all platforms might allow a actor who controls dependency version strings in a project's package.json file to execute arbitrary commands on the host running the CDK toolchain via injected shell metacharacters in the OsCommand helper. This issue requires the actor to control the content of a package.json dependency version string that is processed during Docker-based bundling with nodeModu

A record user with UPDATE access could read field values that field-level SELECT permissions hid from them. Arithmetic operators and `extend` embedded the raw operand into their error messages, and UPDATE permission checks evaluate against the unreduced document — so triggering such an error against a hidden field returned its value in the resulting error. ### Impact A record user issues an UPDATE that performs an incompatible operation against a hidden field — e.g. `UPDATE person:me SET probe

A `LIVE SELECT` subscription records the user's auth state (`$auth`, `$token`, `$session`, `$access`) when it is registered, and the server uses that recorded state to evaluate the table- and row-level `PERMISSIONS` clauses for every subsequent notification. The recorded state is never refreshed. When something changes the user's effective auth state — the originating session is invalidated, the session's TTL expires, or the user signs in, signs up, or authenticates as a different identity on

An anonymous caller could degrade `/sql` availability by streaming WebSocket frames many times larger than the operator-configured per-connection limit. The `/sql` upgrade handler accepted anonymous connections and did not propagate `SURREAL_WEBSOCKET_MAX_MESSAGE_SIZE` to the WebSocket protocol layer — incoming bytes accumulated in the per-connection read buffer before `check_anon` could reject the query, so the memory cost was incurred regardless of whether the caller could ever execute Surreal

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 im

A `LIVE` query whose `WHERE` clause evaluates to an error caused the source data modifier (the user creating, updating, or deleting a record on the watched table) to fail instead. Calling any arbitrary SurrealQL function with a typed parameter and passing a value of the wrong type — for example `LIVE SELECT * FROM t WHERE string::trim(deny)` — triggered an evaluation error inside the LIVE notification path. That error then propagated through to the triggering write, rolling back the attempted ch

An authenticated user could bypass permission rules that gated access on parts of a record's id — most commonly tenant-isolation rules of the form `PERMISSIONS FOR select WHERE id.tenant = $auth.id.tenant`. The same defect also let UNIQUE constraints defined on parts of an id admit duplicate entries. When a query referenced part of a composite record id (`id.tenant`, `id.uid`, …), SurrealDB read the value from the record's editable body fields instead of from the immutable id key. Because the b

An authenticated record or scope user could read records on any table reachable through a graph edge or `REFERENCES TO` back-reference, regardless of that table's `PERMISSIONS FOR select` clause. Traversing `SELECT * FROM source->edge->target` returned full documents from `target` even when `target` was defined as `PERMISSIONS FOR select NONE`. The same bypass extended through multi-hop chains, so any table reachable by a sequence of edges from a readable starting point was exposed. The root c

Multiple weaponized proof-of-concept (PoC) exploits on GitHub delivered a Python-based remote access trojan (RAT) called ChocoPoC that can execute commands and steal sensitive data. [...]

Multiple weaponized proof-of-concept (PoC) exploits on GitHub were found delivering a Python-based remote access trojan (RAT) named ChocoPoC that can execute commands and steal sensitive data in a campaign believed to target cybersecurity researchers. [...]

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`, `INS