continuwuation/continuwuity

Watch

Fork 132

chore(deps): update rust crate rustls to v0.23.46 [security] #2367

Merged

Jade merged 1 commit from renovate/crate-rustls-vulnerability into main

2026-10-15 10:11:26 +00:00

renovate commented

2026-10-15 05:18:04 +00:00

Collaborator

This PR contains the following updates:

Package	Type	Update	Change
rustls	workspace.dependencies	patch	`0.23.45` → `0.23.46`

`Debug` impls for client session values expose TLS secrets

GHSA-c8m5-c952-6cm4 / RUSTSEC-2026-0346

More information

Details

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.

Severity

CVSS Score: 4.0 / 10 (Medium)
Vector String: CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:N/A:N

References

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).

Buffered application data sent to outer server after ECH rejection

GHSA-vp88-798v-h67f / RUSTSEC-2026-0347

More information

Details

When a server rejects Encrypted Client Hello (ECH), the client completes the
handshake using the outer ClientHello and authenticates the server against the
ECH config's public_name. At the end of that handshake, rustls encrypted and
queued any application data buffered via ClientConnection::writer() before
queueing the ech_required alert.

The application correctly receives
Error::PeerIncompatible(ServerRejectedEncryptedClientHello), but the next
write_tls() call (needed to send the alert) also sends the buffered
application data. Plaintext meant for the inner server therefore goes to the
client-facing server named by public_name.

That server is authenticated, so this is not exploitable by an unauthenticated
party, but it violates RFC 9849 section 6.1.6, which requires the client to
abort with ech_required "before sending any application data to the server".

This affects only clients that:

use EchMode::Enable (GREASE ECH is not affected),
write application data before the handshake completes, and
connect to a server that rejects their ECH config (for example, because it is stale).

The underlying ordering bug is older, but before 0.23.44 the client checked
the server certificate against the inner server name rather than public_name,
so certificate verification failed first and no data was sent.

Severity

CVSS Score: 2.3 / 10 (Low)
Vector String: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).

Brotli certificate decompression can allocate up to 1 GiB before authentication

GHSA-h2v8-394m-p7vv / RUSTSEC-2026-0348

More information

Details

The built-in Brotli certificate decompressor (enabled by the non-default
brotli crate feature) bounded the size of the decompressed output, but
accepted a peer-selected history window. Brotli's large-window extension was
enabled, so a five-byte header could cause an allocation of 1 GiB. A peer can
abort a process whose allocator cannot satisfy that request.

No trusted certificate is required by the attacker. Affected configurations are:

clients that enable the brotli feature and connect to a malicious server, and
servers that enable the brotli feature and request client certificates.

Applications that do not enable the brotli feature are not affected.

Severity

CVSS Score: 3.7 / 10 (Low)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).

Unauthenticated ServerHello can downgrade later connections to classical key exchange

GHSA-w44r-93j7-qv28 / RUSTSEC-2026-0349

More information

Details

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.

Severity

CVSS Score: 3.7 / 10 (Low)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [rustls](https://github.com/rustls/rustls) | workspace.dependencies | patch | `0.23.45` → `0.23.46` | --- ### `Debug` impls for client session values expose TLS secrets [GHSA-c8m5-c952-6cm4](https://github.com/advisories/GHSA-c8m5-c952-6cm4) / [RUSTSEC-2026-0346](https://rustsec.org/advisories/RUSTSEC-2026-0346.html) <details> <summary>More information</summary> #### Details 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](https://github.com/rustls/rustls/blob/99f2358cae2954837dbb866faf6727de75489ab9/SECURITY.md#boundary-public-api). Ordinary connection and built-in session cache `Debug` output is redacted and is not affected. #### Severity - CVSS Score: 4.0 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:N/A:N` #### References - [https://crates.io/crates/rustls](https://crates.io/crates/rustls) - [https://rustsec.org/advisories/RUSTSEC-2026-0346.html](https://rustsec.org/advisories/RUSTSEC-2026-0346.html) - [https://github.com/rustls/rustls/pull/3299](https://github.com/rustls/rustls/pull/3299) This data is provided by [OSV](https://osv.dev/vulnerability/RUSTSEC-2026-0346) and the [Rust Advisory Database](https://github.com/RustSec/advisory-db) ([CC0 1.0](https://github.com/rustsec/advisory-db/blob/main/LICENSE.txt)). </details> --- ### Buffered application data sent to outer server after ECH rejection [GHSA-vp88-798v-h67f](https://github.com/advisories/GHSA-vp88-798v-h67f) / [RUSTSEC-2026-0347](https://rustsec.org/advisories/RUSTSEC-2026-0347.html) <details> <summary>More information</summary> #### Details When a server rejects Encrypted Client Hello (ECH), the client completes the handshake using the outer ClientHello and authenticates the server against the ECH config's `public_name`. At the end of that handshake, rustls encrypted and queued any application data buffered via `ClientConnection::writer()` *before* queueing the `ech_required` alert. The application correctly receives `Error::PeerIncompatible(ServerRejectedEncryptedClientHello)`, but the next `write_tls()` call (needed to send the alert) also sends the buffered application data. Plaintext meant for the inner server therefore goes to the client-facing server named by `public_name`. That server is authenticated, so this is not exploitable by an unauthenticated party, but it violates RFC 9849 section 6.1.6, which requires the client to abort with `ech_required` "before sending any application data to the server". This affects only clients that: - use `EchMode::Enable` (GREASE ECH is not affected), - write application data before the handshake completes, and - connect to a server that rejects their ECH config (for example, because it is stale). The underlying ordering bug is older, but before 0.23.44 the client checked the server certificate against the inner server name rather than `public_name`, so certificate verification failed first and no data was sent. #### Severity - CVSS Score: 2.3 / 10 (Low) - Vector String: `CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` #### References - [https://crates.io/crates/rustls](https://crates.io/crates/rustls) - [https://rustsec.org/advisories/RUSTSEC-2026-0347.html](https://rustsec.org/advisories/RUSTSEC-2026-0347.html) - [https://github.com/rustls/rustls/pull/3300](https://github.com/rustls/rustls/pull/3300) This data is provided by [OSV](https://osv.dev/vulnerability/RUSTSEC-2026-0347) and the [Rust Advisory Database](https://github.com/RustSec/advisory-db) ([CC0 1.0](https://github.com/rustsec/advisory-db/blob/main/LICENSE.txt)). </details> --- ### Brotli certificate decompression can allocate up to 1 GiB before authentication [GHSA-h2v8-394m-p7vv](https://github.com/advisories/GHSA-h2v8-394m-p7vv) / [RUSTSEC-2026-0348](https://rustsec.org/advisories/RUSTSEC-2026-0348.html) <details> <summary>More information</summary> #### Details The built-in Brotli certificate decompressor (enabled by the non-default `brotli` crate feature) bounded the size of the decompressed output, but accepted a peer-selected history window. Brotli's large-window extension was enabled, so a five-byte header could cause an allocation of 1 GiB. A peer can abort a process whose allocator cannot satisfy that request. No trusted certificate is required by the attacker. Affected configurations are: - clients that enable the `brotli` feature and connect to a malicious server, and - servers that enable the `brotli` feature and request client certificates. Applications that do not enable the `brotli` feature are not affected. #### Severity - CVSS Score: 3.7 / 10 (Low) - Vector String: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L` #### References - [https://crates.io/crates/rustls](https://crates.io/crates/rustls) - [https://rustsec.org/advisories/RUSTSEC-2026-0348.html](https://rustsec.org/advisories/RUSTSEC-2026-0348.html) - [https://github.com/rustls/rustls/pull/3297](https://github.com/rustls/rustls/pull/3297) This data is provided by [OSV](https://osv.dev/vulnerability/RUSTSEC-2026-0348) and the [Rust Advisory Database](https://github.com/RustSec/advisory-db) ([CC0 1.0](https://github.com/rustsec/advisory-db/blob/main/LICENSE.txt)). </details> --- ### Unauthenticated ServerHello can downgrade later connections to classical key exchange [GHSA-w44r-93j7-qv28](https://github.com/advisories/GHSA-w44r-93j7-qv28) / [RUSTSEC-2026-0349](https://rustsec.org/advisories/RUSTSEC-2026-0349.html) <details> <summary>More information</summary> #### Details 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](https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations), so the practical impact depends largely on server policy. #### Severity - CVSS Score: 3.7 / 10 (Low) - Vector String: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N` #### References - [https://crates.io/crates/rustls](https://crates.io/crates/rustls) - [https://rustsec.org/advisories/RUSTSEC-2026-0349.html](https://rustsec.org/advisories/RUSTSEC-2026-0349.html) - [https://github.com/rustls/rustls/pull/3355](https://github.com/rustls/rustls/pull/3355) This data is provided by [OSV](https://osv.dev/vulnerability/RUSTSEC-2026-0349) and the [Rust Advisory Database](https://github.com/RustSec/advisory-db) ([CC0 1.0](https://github.com/rustsec/advisory-db/blob/main/LICENSE.txt)). </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate).

renovate added the

Dependencies

Dependencies/Renovate

labels

2026-10-15 05:18:04 +00:00

renovate added 1 commit

2026-10-15 05:18:04 +00:00

chore(deps): update rust crate rustls to v0.23.46 [security]

Auto Labeler / Apply labels based on changed files (pull_request_target) Successful in 3s

Details

Checks / Prek / Check changed files (pull_request) Successful in 6s

Details