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

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
rustls	workspace.dependencies	patch	0.23.40 → 0.23.46

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Rustls: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries

GHSA-2mjx-qc3c-rqvc

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::aligned considers 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

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

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 Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

• https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
• https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7
• https://github.com/rustls/rustls/commit/98456aea708a7e3c6151e00ca2d4428e7a58257a
• https://rustsec.org/advisories/RUSTSEC-2026-0285.html
• https://github.com/advisories/GHSA-2mjx-qc3c-rqvc

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Rustls: 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::aligned considers 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

Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.

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 Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

• https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
• https://github.com/golang/go/commit/5046bdf8a612b35a2c1a9e168054c1d5c65e7dd7
• https://github.com/rustls/rustls/commit/98456aea708a7e3c6151e00ca2d4428e7a58257a
• https://github.com/rustls/rustls
• https://rustsec.org/advisories/RUSTSEC-2026-0285.html

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 EncryptedExtensions message packed into the same record as the
ServerHello was 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 Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

• https://crates.io/crates/rustls
• https://rustsec.org/advisories/RUSTSEC-2026-0285.html
• https://github.com/rustls/rustls/pull/3265

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

---

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

• https://crates.io/crates/rustls
• https://rustsec.org/advisories/RUSTSEC-2026-0346.html
• https://github.com/rustls/rustls/pull/3299

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

• https://crates.io/crates/rustls
• https://rustsec.org/advisories/RUSTSEC-2026-0348.html
• https://github.com/rustls/rustls/pull/3297

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

• https://crates.io/crates/rustls
• https://rustsec.org/advisories/RUSTSEC-2026-0349.html
• https://github.com/rustls/rustls/pull/3355

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 was generated by Mend Renovate. View the repository job log.