Repository navigation
Security patches (stable/2.0.x) - #398
Merged
t-aleksander merged 1 commit intoOct 23, 2026
Merged
Conversation
renovate
Bot
added
dependencies
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.43→0.23.460.103.13→0.103.16Rustls: 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).
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).
Certificate verification may accept distrusted intermediates
CVE-2026-111943 / GO-2026-6809 / RUSTSEC-2026-0381 / RUSTSEC-2026-0382 / RUSTSEC-2026-0383
More information
Details
Affected versions may accept certificate paths containing distrusted emSign
intermediate public keys when the configured trust anchors allow such paths.
The private keys corresponding to these intermediates are now well known.
Versions 0.103.16 and 0.104.0-alpha.8 reject paths containing these public keys.
Severity
Unknown
References
This data is provided by OSV and the Rust Advisory Database (CC0 1.0).
Configuration
📅 Schedule: (in timezone Europe/Warsaw)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR was generated by Mend Renovate. View the repository job log.