The Debug implementations of Tls12ClientSessionValue and Tls13ClientSessionValue were derived, and so included the TLS 1.2 master secret or TLS 1.3 resumption PSK in their output.

Custom ClientSessionStore implementations that format these values with Debug (for example, when logging) could disclose these secrets to readers of the logs. This conflicts with rustls's key-material redaction policy.

Ordinary connection and built-in session cache Debug output is redacted and is not affected.

The client recorded the server-selected key exchange group for each server name when processing the ServerHello, before the server was authenticated. This record is used to predict which key share to send in future ClientHellos to that server name.

A network attacker can answer one connection attempt with a ServerHello selecting X25519, and then close the connection. Later ClientHellos for that name carry only an X25519 key share, while supported_groups still lists X25519MLKEM768 first. If the genuine server accepts that share rather than sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical-only key exchange and no error. This persists for as long as the entry stays in the client's session store.

The impact is loss of post-quantum confidentiality for affected connections ("harvest now, decrypt later"). There is no key compromise and no authentication bypass.

The following are not affected:

• connections to servers which send a HelloRetryRequest for their preferred group,
• clients with resumption disabled (as nothing is stored), and
• other server names.

This behaviour is discussed in draft-ietf-tls-key-share-prediction, so the practical impact depends largely on server policy.

dbs::Executor drives every SurrealQL statement through reblessive::tree::TreeStack. In reblessive 0.4.3 the runtime types unconditionally assert Send/Sync (unsafe impl Send/Sync for Stack, TreeStack and Runner), while the public entry points accept any future without a Send bound and store it type-erased in a bump allocator.

Two safe-code consequences follow. First, Runner::step_async/finish_async return driver futures tied to the stack borrow rather than to &mut self, so a driver future can be duplicated; because Stack is Sync those futures are Send, and polling two copies on different threads runs drive_top_task concurrently — racy Cell/UnsafeCell access, double pop_task()/pop_dealloc() (double drop / double free) and a non-atomic Option::take. Second, TreeStack: Send lets safe code move a driver whose type-erased future captures !Send state (Rc, RefCell) to another thread while the creating thread keeps an alias of that state.

No unsafe is needed at the call site. surrealdb-core's own query futures are Send only because of the unsound unsafe impl Send for TreeStack, while the captured &mut tree::Stk is deliberately !Send.

The unsound dependency was removed in 4.0.0 and the parser now uses plain recursion (commit 75407c4bcc).