Rustls
Monthly
rustls 0.23.13 through 0.23.44 accepts TLS 1.3 handshake messages delivered at the wrong encryption level when a key-changing message and a following handshake message are packed into the same record. The practical effect is that a malicious TLS peer (for example a hostile server) or an on-path attacker can deliver a plaintext EncryptedExtensions alongside the ServerHello and have rustls process it instead of terminating the connection with an unexpected_message alert, which is a limited information-disclosure style failure to enforce RFC 8446 record-boundary rules. The handshake transcript remains cryptographically authenticated, so the attacker cannot alter or complete a handshake, impersonate a peer, or downgrade the connection; no public exploit code was identified at time of analysis and the CVE is not in CISA KEV. Vendor-released patch: 0.23.45, and vuln.today triage places remediation in the this_month window rather than an emergency response.
Information disclosure in rustls 0.23.44 and 0.23.45 causes application data that a client buffers before the TLS handshake completes to be encrypted and transmitted to the client-facing (outer) server when that server rejects Encrypted Client Hello, instead of being discarded before the fatal ech_required alert is sent. Only clients that use EchMode::Enable (GREASE ECH is explicitly not affected), write application data before the handshake finishes, and connect to a server that rejects their ECH config are exposed, and the recipient is the properly authenticated public_name server rather than an arbitrary or unauthenticated party, which sharply limits real-world risk. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor has released fixes in 0.23.46 and 0.24.0-dev.2.
rustls clients before 0.23.46 can be steered into classical-only TLS 1.3 key exchange by an unauthenticated network attacker who answers a single connection attempt for a target name with a ServerHello selecting X25519, poisoning the client's per-server-name key-exchange group record so later ClientHellos for that name carry only a classical share even though supported_groups still lists X25519MLKEM768 first. The downgrade only completes if the genuine server accepts that lone X25519 share instead of issuing a HelloRetryRequest for its preferred hybrid group; when it does, the handshake finishes without error and post-quantum confidentiality is silently lost for those sessions, with no key compromise and no authentication bypass. No public exploit has been identified at time of analysis, and clients configured with resumption disabled store nothing and do not trigger the issue.
Memory exhaustion in rustls can abort Brotli-enabled clients or client-authenticating servers when a malicious peer sends a certificate with a five-byte Brotli header requesting up to a 1 GiB window before authentication. The issue affects rustls before 0.23.46 and 0.24.0-dev.1 through 0.24.0-dev.2 when the optional, default-disabled brotli feature is compiled in and enabled; clients are exposed when they enable brotli and connect to a malicious server, while servers are exposed only when they enable brotli and request client-certificate authentication. No public exploit code was identified in the provided intelligence, and practical impact depends on the target allocator being unable to satisfy the requested allocation.
Rustls before 0.23.46 and the 0.24.0-dev.1 pre-release can expose TLS 1.2 master secrets or TLS 1.3 resumption PSKs when a custom ClientSessionStore implementation logs or Debug-formats Tls12ClientSessionValue or Tls13ClientSessionValue. Default rustls connection and built-in cache diagnostics remain redacted, so only deployments with such a custom store and a local, high-privilege reader of its logs are affected. No public exploit code was identified at time of analysis; the advisory describes a proof-of-concept logging scenario, and fixed releases are 0.23.46 and 0.24.0-dev.2.
A flaw was found in Rustls 0.23.13 and related APIs. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
rustls-mio/examples/tlsserver.rs in the rustls crate before 0.16.0 for Rust allows attackers to cause a denial of service (loop of conn_event and ready) by arranging for a client to never be writable. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
rustls 0.23.13 through 0.23.44 accepts TLS 1.3 handshake messages delivered at the wrong encryption level when a key-changing message and a following handshake message are packed into the same record. The practical effect is that a malicious TLS peer (for example a hostile server) or an on-path attacker can deliver a plaintext EncryptedExtensions alongside the ServerHello and have rustls process it instead of terminating the connection with an unexpected_message alert, which is a limited information-disclosure style failure to enforce RFC 8446 record-boundary rules. The handshake transcript remains cryptographically authenticated, so the attacker cannot alter or complete a handshake, impersonate a peer, or downgrade the connection; no public exploit code was identified at time of analysis and the CVE is not in CISA KEV. Vendor-released patch: 0.23.45, and vuln.today triage places remediation in the this_month window rather than an emergency response.
Information disclosure in rustls 0.23.44 and 0.23.45 causes application data that a client buffers before the TLS handshake completes to be encrypted and transmitted to the client-facing (outer) server when that server rejects Encrypted Client Hello, instead of being discarded before the fatal ech_required alert is sent. Only clients that use EchMode::Enable (GREASE ECH is explicitly not affected), write application data before the handshake finishes, and connect to a server that rejects their ECH config are exposed, and the recipient is the properly authenticated public_name server rather than an arbitrary or unauthenticated party, which sharply limits real-world risk. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor has released fixes in 0.23.46 and 0.24.0-dev.2.
rustls clients before 0.23.46 can be steered into classical-only TLS 1.3 key exchange by an unauthenticated network attacker who answers a single connection attempt for a target name with a ServerHello selecting X25519, poisoning the client's per-server-name key-exchange group record so later ClientHellos for that name carry only a classical share even though supported_groups still lists X25519MLKEM768 first. The downgrade only completes if the genuine server accepts that lone X25519 share instead of issuing a HelloRetryRequest for its preferred hybrid group; when it does, the handshake finishes without error and post-quantum confidentiality is silently lost for those sessions, with no key compromise and no authentication bypass. No public exploit has been identified at time of analysis, and clients configured with resumption disabled store nothing and do not trigger the issue.
Memory exhaustion in rustls can abort Brotli-enabled clients or client-authenticating servers when a malicious peer sends a certificate with a five-byte Brotli header requesting up to a 1 GiB window before authentication. The issue affects rustls before 0.23.46 and 0.24.0-dev.1 through 0.24.0-dev.2 when the optional, default-disabled brotli feature is compiled in and enabled; clients are exposed when they enable brotli and connect to a malicious server, while servers are exposed only when they enable brotli and request client-certificate authentication. No public exploit code was identified in the provided intelligence, and practical impact depends on the target allocator being unable to satisfy the requested allocation.
Rustls before 0.23.46 and the 0.24.0-dev.1 pre-release can expose TLS 1.2 master secrets or TLS 1.3 resumption PSKs when a custom ClientSessionStore implementation logs or Debug-formats Tls12ClientSessionValue or Tls13ClientSessionValue. Default rustls connection and built-in cache diagnostics remain redacted, so only deployments with such a custom store and a local, high-privilege reader of its logs are affected. No public exploit code was identified at time of analysis; the advisory describes a proof-of-concept logging scenario, and fixed releases are 0.23.46 and 0.24.0-dev.2.
A flaw was found in Rustls 0.23.13 and related APIs. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
rustls-mio/examples/tlsserver.rs in the rustls crate before 0.16.0 for Rust allows attackers to cause a denial of service (loop of conn_event and ready) by arranging for a client to never be writable. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.