CVE-2026-123609 in Rustls
Summary
by MITRE • 11/08/2026
Rustls before 0.23.46 and 0.24.0-dev.1 before 0.24.0-dev.2 contains an information disclosure vulnerability where derived Debug formatting of client session values exposes secret key material. Custom ClientSessionStore implementations that log Tls12ClientSessionValue or Tls13ClientSessionValue can leak TLS 1.2 master secrets or TLS 1.3 resumption PSKs to log readers.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/08/2026
The vulnerability identified in Rustls versions prior to 0.23.46 and the development branch leading up to version 0.24.0-dev.2 represents a critical information disclosure flaw rooted in improper handling of sensitive cryptographic material during debugging operations. Specifically, the issue arises from the implementation of Debug formatting traits for internal client session structures, namely Tls12ClientSessionValue and Tls13ClientSessionValue. In Rust-based ecosystems, these traits are often utilized by developers to print or log object states for troubleshooting purposes. However, in this specific context, the default debug implementations inadvertently expose high-value secret key material rather than sanitized placeholders or identifiers. This design oversight means that any code path invoking standard debugging output mechanisms on these session objects will result in the serialization of cryptographic secrets into text-based logs.
The operational impact of this vulnerability is severe due to the nature of TLS session keys. For connections utilizing TLS 1.2, the exposed data includes the master secret, which serves as the root key material from which all subsequent encryption and message authentication codes are derived. Compromise of this value allows an attacker with access to the logs to decrypt past recorded traffic if they also possess the server's long-term private key, effectively breaking forward secrecy for those sessions. In TLS 1.3 environments, the vulnerability exposes resumption pre-shared keys or PSKs. These values are crucial for session resumption and early data transmission; their leakage enables potential man-in-the-middle attacks where an adversary can impersonate either party in future connections established using these resumed parameters. This undermines the confidentiality guarantees provided by the TLS protocol itself.
From a classification perspective, this vulnerability aligns with CWE-209, which describes the generation of error messages containing sensitive information that could be utilized by attackers to gain further knowledge of the system. It also relates closely to CWE-359, involving exposure of private personal information or credentials through unintended channels. In terms of adversarial tactics as defined by MITRE ATT&CK, this flaw facilitates Information Collection via Log Enumeration and potentially supports Lateral Movement if session keys are reused across multiple services within a network infrastructure. The vulnerability is particularly dangerous because it often occurs in non-production environments during development but can persist into production if logging levels are adjusted or if debug builds are inadvertently deployed without proper sanitization of sensitive fields.
Mitigation strategies must focus on immediate version upgrades and rigorous code review practices regarding cryptographic object handling. Organizations utilizing Rustls should upgrade to version 0.23.46 or later, as well as the stable release following 0.24.0-dev.2, where these debug implementations have been corrected to exclude secret material from standard output streams. For custom ClientSessionStore implementations that log Tls12ClientSessionValue or Tls13ClientSessionValue, developers must explicitly override Debug formatting methods to ensure that only non-sensitive metadata such as session identifiers or timestamps are recorded. Implementing a secure logging framework that automatically redacts known sensitive patterns can provide an additional layer of defense against accidental exposure. Regular audits of log outputs and configuration settings should be conducted to verify that no cryptographic keys, certificates with private components, or authentication tokens are inadvertently written to persistent storage or standard output streams during normal application operation.