Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.3",
  "pubDate": "2026-08-17T11:16:41.293Z",
  "pubdate": "2026-08-17T11:16:41.293Z",
  "executiveSummary": "An information exposure vulnerability exists in the openssl_encrypt pip package versions <= 1.4.7. The flaw manifests when executing specific diagnostic commands, namely 'hsm fido2-test' and 'hsm onlykey-test', which unconditionally leak sensitive cryptographic material by printing the full derived hardware pepper as hexadecimal data to standard output or standard error. Additionally, a related plugin issue logs raw prf_data outside the established secret-redaction path.\nThe primary risk associated with this exposure involves the persistence of sensitive data within terminal scrollback buffers, user session recordings, and continuous integration (CI) execution logs. However, the operational impact is strictly limited due to the cryptographic properties of the leaked artifact; the pepper is derived from a random per-invocation test salt and remains strictly salt-bound. Consequently, unauthorized entities cannot leverage the exposed value to decrypt arbitrary real-world files.\nAttacker capabilities are constrained to observing historical logs, terminal buffers, or debugging streams where the diagnostic commands were previously executed. Exploitation requires the prior execution of the vulnerable diagnostic commands within an environment accessible to the observer. Remediation involves upgrading to version 1.4.8 or 1.5.0, which removes the insecure hex dumps and correctly routes plugin debug output through the proper secret-redaction layer.",
  "technicalDetails": "The root cause of the vulnerability resides in insecure logging and diagnostic output handling within the crypt_cli.py file, specifically inside the handle_hsm_command function. During the execution of the 'hsm fido2-test' and 'hsm onlykey-test' diagnostic routines, the application processes cryptographic material and inadvertently prints the full derived hardware pepper directly to stdout and stderr without applying any masking or sanitization mechanisms.\nFurthermore, a secondary vector involves plugin-level execution where raw prf_data is logged directly, bypassing the intended secret-redaction path entirely. These design flaws result in sensitive cryptographic values being written to any medium capturing the standard streams of the process, including host terminal buffers, persistent CI build logs, and unencrypted session recordings.\nThe attack flow proceeds as follows: 1) An administrative user or automated testing harness executes the openssl_encrypt CLI utility with either the 'hsm fido2-test' or 'hsm onlykey-test' argument. 2) The handle_hsm_command function within crypt_cli.py derives the hardware pepper for testing purposes. 3) Rather than securely handling or discarding this temporary material, the application formats the derived hardware pepper as a hexadecimal string and writes it unconditionally to the standard output or error streams. 4) Concurrently, any associated plugin operations log raw prf_data outside the redaction layer. 5) Unprivileged local users, log-aggregation systems with overly broad access controls, or malicious actors with access to historical CI artifacts read the exposed hexadecimal pepper from the logs or terminal history.\nDespite the exposure of the derived hardware pepper, the post-exploitation impact remains minimal. Because the pepper is bound to a random test salt generated per invocation, the leaked data cannot be repurposed to decrypt production payloads or real files encrypted by the library. The vulnerability affects openssl_encrypt versions <= 1.4.7 and does not require network exposure, specific authentication levels, or elevated privileges to observe the leakage, provided the observer has read access to the logs or output streams where the diagnostic commands were invoked."
}