Skip to content

fix(deps): update rust crate rustls to 0.23.46 [security] - #621

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/security-cargo
Open

renovate[bot] wants to merge 1 commit into
mainfrom
renovate/security-cargo

Conversation

@renovate

@renovate renovate Bot commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Type Update Change
rustls dependencies patch 0.23 → 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 was generated by Mend Renovate. View the repository job log.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants