CVE-2026-74870 in openssl_encrypt
Summary
by MITRE • 08/17/2026
openssl_encrypt (pip) versions <= 1.4.7 contain an information exposure vulnerability where the 'hsm fido2-test' and 'hsm onlykey-test' diagnostic commands unconditionally print the full derived hardware pepper as hex to stdout/stderr (crypt_cli.py, handle_hsm_command). The printed value can persist in terminal scrollback, session recordings, or CI logs. Impact is limited because the pepper is derived from a random per-invocation test salt and is salt-bound, so the leaked value cannot be used to decrypt real files. A related plugin issue logged raw prf_data outside the secret-redaction path. Fixed in 1.4.8 (and 1.5.0) by removing the hex dumps and routing plugin debug output through the redaction layer.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in openssl_encrypt versions up to 1.4.7 represents a significant information exposure flaw rooted in improper handling of sensitive diagnostic data during hardware security module testing procedures. Specifically, within the crypt_cli.py module's handle_hsm_command function, two distinct diagnostic commands designed for FIDO2 and OnlyKey hardware tokens were configured to unconditionally output the full derived hardware pepper as hexadecimal strings directly to standard output or standard error streams. This behavior bypasses established secret-redaction protocols that are typically employed in production environments to mask sensitive cryptographic material such as keys, passwords, and derivation seeds. The presence of this plaintext data in console outputs creates a direct pathway for unauthorized information disclosure, particularly in automated or logged execution contexts where terminal history is preserved.
The operational impact of this vulnerability extends beyond the immediate display on a user's screen due to the persistence mechanisms inherent in modern computing environments. Terminal scrollback buffers often retain large volumes of historical output, which can be inadvertently copied and shared by users unaware of the sensitivity of the displayed data. Furthermore, in continuous integration and deployment pipelines, as well as remote session recordings or server logs, these diagnostic outputs are frequently captured and stored indefinitely. This persistence transforms a transient display error into a long-term security risk, as the leaked hexadecimal values remain accessible to anyone with read access to those log files or terminal histories. The exposure of hardware-specific peppers compromises the integrity of the testing environment by revealing internal state information that should remain isolated from external observation channels.
Despite the severity of the data leakage mechanism, the actual cryptographic impact is mitigated by the specific nature of how the pepper was generated for these test operations. The leaked value corresponds to a derived key material bound to a random salt unique to each invocation of the diagnostic command. Because this salt changes with every run and the resulting pepper is not used as a master key for encrypting persistent user data, the exposed hexadecimal string cannot be reverse-engineered or reused to decrypt real files stored by the application. This distinction limits the vulnerability from being classified as a critical break in confidentiality for production assets, yet it remains a high-severity configuration error that violates principles of least privilege and secure logging practices. The related issue involving raw prf_data leakage outside secret-redaction paths further compounds this risk by exposing additional internal cryptographic parameters that could aid attackers in understanding the system's key derivation logic if combined with other vulnerabilities.
To address these deficiencies, the vulnerability was resolved in version 1.4.8 and subsequently included in version 1.5.0 through a comprehensive review of output handling mechanisms. The fix involves removing the unconditional hexadecimal dumps from the diagnostic commands entirely to prevent any accidental exposure during normal operation. Additionally, plugin debug outputs are now routed through a dedicated redaction layer that actively masks sensitive cryptographic material before it reaches standard streams. This architectural change ensures that even if debugging information is logged for troubleshooting purposes, no secret values such as hardware peppers or pseudo-random function data will be visible in plaintext. Organizations utilizing affected versions should upgrade immediately to eliminate the risk of log-based credential leakage and align their security posture with industry standards regarding secure logging practices.
From a classification perspective, this vulnerability maps directly to CWE-209 which describes the generation of an error message that includes sensitive information about the resources from which the error was generated. It also relates closely to CWE-532 concerning log file exposure and CWE-798 for use of hardcoded credentials or keys when considering the static nature of some test salts if not properly randomized, though here the primary issue is the lack of redaction in dynamic outputs. In terms of adversary tactics, this aligns with ATT&CK technique T1005 which involves data from local system retrieval, as an attacker could potentially harvest these logs to gain insights into cryptographic implementations or testing frameworks. Mitigation strategies must prioritize strict separation between debug output and production logging channels, ensuring that all sensitive material is processed through sanitization routines before being written to any persistent storage medium accessible by non-privileged users.