Update Rust crate rustls to v0.23.46 [SECURITY] #71
No reviewers
Labels
No labels
bug
dart
dependencies
documentation
duplicate
enhancement
github-actions
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Evobug/TKit!71
Loading…
Reference in a new issue
No description provided.
Delete branch "renovate/crate-rustls-vulnerability"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
0.23.45→0.23.46Debugimpls for client session values expose TLS secretsGHSA-c8m5-c952-6cm4 / RUSTSEC-2026-0346
More information
Details
The
Debugimplementations ofTls12ClientSessionValueandTls13ClientSessionValuewere derived, and so included the TLS 1.2 mastersecret or TLS 1.3 resumption PSK in their output.
Custom
ClientSessionStoreimplementations that format these values withDebug(for example, when logging) could disclose these secrets to readers ofthe logs. This conflicts with rustls's
key-material redaction policy.
Ordinary connection and built-in session cache
Debugoutput is redacted andis not affected.
Severity
CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:N/A:NReferences
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 andqueued any application data buffered via
ClientConnection::writer()beforequeueing the
ech_requiredalert.The application correctly receives
Error::PeerIncompatible(ServerRejectedEncryptedClientHello), but the nextwrite_tls()call (needed to send the alert) also sends the bufferedapplication 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:
EchMode::Enable(GREASE ECH is not affected),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:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:NReferences
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
brotlicrate feature) bounded the size of the decompressed output, butaccepted 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:
brotlifeature and connect to a malicious server, andbrotlifeature and request client certificates.Applications that do not enable the
brotlifeature are not affected.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
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_groupsstill listsX25519MLKEM768 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:
This behaviour is discussed in
draft-ietf-tls-key-share-prediction,
so the practical impact depends largely on server policy.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:NReferences
This data is provided by OSV and the Rust Advisory Database (CC0 1.0).
Configuration
📅 Schedule: (in timezone Europe/Prague)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate CLI.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.