Repository navigation
Update Rust crate rustls to v0.23.46 [SECURITY] - #219
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.23.40→0.23.46Rustls: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
GHSA-2mjx-qc3c-rqvc / RUSTSEC-2026-0285
More information
Details
Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level when they followed a key-changing message in the same record. The handshake transcript is still authenticated, so a network-position attacker cannot use this to alter or complete a handshake; the practical effect is that a peer could send handshake messages that should be encrypted in plaintext without rustls rejecting the connection.
This issue affects rustls versions 0.23.13 through 0.23.44 inclusive.
Original report
Summary
Rustls (tested version 0.23.44, and it appears still an issue on latest master though I have not tested this) accepts a TLS 1.3 server flight where a plaintext EncryptedExtensions is packed into the same record as the ServerHello.
This is very similar to Go's CVE-2025-61730 fixed in golang/go@5046bdf
Details
It appears
Deframer::alignedconsiders itself aligned as long as all messages remaining in the buffer are complete. Rustls processes the ServerHello, installs the handshake keys, then pulls the complete (plaintext) EncryptedExtensions out of the buffer.This is insufficient per RFC 8446 section 5.1's
Impact
An on path attacker can inject plaintext messages that are accepted.
Tool Use Disclosure
This was discovered by a new TLS/DTLS test suite currently under construction. The specific testcase was inspired by the Go CVE. Other tested implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) reject this protocol flow. Daybreak Blue reviewed the rustls code to identify probable root cause.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
GHSA-2mjx-qc3c-rqvc / RUSTSEC-2026-0285
More information
Details
Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
when they followed a key-changing message in the same record. For example,
a plaintext
EncryptedExtensionsmessage packed into the same record as theServerHellowas accepted.RFC 8446 section 5.1 requires that handshake messages do not span key changes,
and that implementations terminate the connection with an "unexpected_message"
alert if they do.
The handshake transcript is still authenticated, so a network-position attacker
cannot use this to alter or complete a handshake; the practical effect is that
a peer could send handshake messages that should be encrypted in plaintext
without rustls rejecting the connection.
This is functionally the same bug as Go's
GO-2026-4340 (CVE-2025-61730).
Severity
CVSS:3.1/AV:N/AC:L/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).
Rustls: Session Debug formatting exposes TLS master secrets and resumption PSKs
GHSA-c8m5-c952-6cm4 / RUSTSEC-2026-0346
More information
Details
Summary
Formatting a client session value with Debug exposes its TLS 1.2 master secret or TLS 1.3 resumption PSK. A custom session store that logs these values can disclose keys to readers of the logs. Ordinary connection and built-in cache diagnostics remain redacted, and the session-store interface already warns that its values are sensitive.
Details
Derived formatters traverse the session's secret-bearing fields. This conflicts with the project's explicit key-material redaction policy.
Proof of concept
Custom
ClientSessionStoreimplementations could leak secret data by using the providedTls12ClientSessionValueorTls13ClientSessionValuein a way that triggers its implementation of theDebugtrait.Impact
Such store implementations could leak the master secret for the TLS connection.
Acknowledgement
Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.
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 GitHub Advisory Database (CC-BY 4.0).
Rustls: Brotli certificate decompression can allocate an attacker-controlled amount of memory up to 1 GiB before authentication.
GHSA-h2v8-394m-p7vv / RUSTSEC-2026-0348
More information
Details
Summary
The built-in (but disabled by default) Brotli certificate decoder bounds the output buffer but accepts an input-selected history window. A header of five bytes can specify a 1 GiB window allocation. A peer can abort a process whose allocator cannot satisfy that request. A client must enable Brotli and connect to the peer; a server must enable Brotli and request a client certificate. Neither direction requires a trusted attacker certificate.
Details
rustls calls
BrotliDecompresswhich enables Brotli's large-window extension. rustls applies a limit to certificates, but this applies to the decompressed result, and not to any internal allocations the process requires.Impact
Client applications that enable the
brotlifeature will be vulnerable to malicious servers. Server applications that enable thebrotlifeature and enable client authentication will be vulnerable to malicious clients.Potential for denial of service due to memory exhaustion from peers sending malicious Brotli-encoded certificates, for applications that enable Brotli decompression.
Acknowledgement
Thanks to OpenAI OutboundDisclosures@openai.com for the disclosure.
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 GitHub Advisory Database (CC-BY 4.0).
rustls: An unauthenticated ServerHello poisons the per-name key-exchange record, so later ClientHellos carry only a classical X25519 share
GHSA-w44r-93j7-qv28 / RUSTSEC-2026-0349
More information
Details
Summary
The client records the server-selected key-exchange group per server name when it processes the ServerHello, before the server is authenticated. A network attacker can answer one connection attempt for a target name with a ServerHello that selects X25519 and close the connection. Later ClientHellos for that name carry one X25519 share while supported_groups still lists X25519MLKEM768 first. If the server accepts that share instead of sending a HelloRetryRequest, the handshake completes with classical key exchange only and no error.
An attacker that answers one connection attempt for the target name with a ServerHello selecting X25519 changes every later ClientHello of that client for that name, for as long as the entry stays in the store. No certificate or completed handshake is needed: it parses the ClientHello, sends the ServerHello, and closes.
TLS 1.3 transcript binding stops an on-path attacker from editing the ClientHello of one connection. It does not stop the attacker from steering the client's prediction state beforehand, because that state is written from an unauthenticated message.
What does not trigger it
Impact
If the genuine server picks the group for which a share is present, instead of sending a HelloRetryRequest for its preferred hybrid group, the handshake completes with classical key exchange only, between two peers that both support the hybrid group. No error is raised. The confidentiality of recorded sessions against a future quantum adversary is lost for those connections (harvest now, decrypt later). There is no key compromise and no authentication bypass.
Note that this behaviour is discussed at length in draft-ietf-tls-key-share-prediction so the actual security impact is largely down to a server policy decision.
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 GitHub Advisory Database (CC-BY 4.0).
Debugimpls 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).
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: (UTC)
🚦 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.
This PR was generated by Mend Renovate. View the repository job log.