CVE-2026-81715 in openssl_encrypt
Summary
by MITRE • 08/27/2026
openssl_encrypt (pip package openssl-encrypt) versions <= 1.4.8 do not redact the keyserver bearer token passed as the positional argument to 'keyserver set-token' in the --debug argv dump, because sanitize_argv_for_debug fails to sanitize it. As a result the token is printed in cleartext to stderr under --debug (even without --unsafe-show-secrets), persisting the credential in logs and terminal history. Fixed in 1.4.9.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The openssl-encrypt Python package, specifically versions up to and including 1.4.8, contains a critical information disclosure vulnerability within its debugging infrastructure. This flaw manifests when users invoke the keyserver configuration command with specific arguments, particularly when setting an authentication token for a remote key server. The application includes a mechanism intended to sanitize command-line arguments before logging them during debug sessions, aiming to prevent sensitive data from appearing in output streams. However, this sanitization logic is incomplete and fails to identify or mask the bearer token passed as a positional argument to the set-token function. Consequently, when the --debug flag is enabled, the raw, unredacted value of the authentication credential is written directly to the standard error stream.
This vulnerability represents a classic case of improper input sanitization leading to sensitive data exposure in logs and console output. The issue persists regardless of whether the user explicitly requests detailed secret visibility through flags like --unsafe-show-secrets, indicating that the default debug behavior itself becomes a vector for credential leakage. Because the token is printed in cleartext, it can be easily captured by anyone with access to the terminal session history or system logs where standard error output is recorded. This exposure compromises the confidentiality of the authentication mechanism used to communicate with the key server, potentially allowing unauthorized parties to impersonate legitimate users if they gain access to these log files or shell histories.
From a security architecture perspective, this flaw aligns closely with CWE-532, which covers information exposure through log files, and CWE-798, involving the use of hardcoded credentials or excessive trust in client-side data handling when sensitive values are not properly masked during processing. In terms of adversary behavior, this vulnerability facilitates reconnaissance and credential theft as described in MITRE ATT&CK technique T1530, which involves collecting data from local system sources such as log files and command history. An attacker with limited access to the host environment could exploit this oversight to harvest valid authentication tokens without needing to bypass complex security controls or inject malicious code into the application logic itself.
The operational impact of this vulnerability is significant for environments where debug logging is enabled, either intentionally by developers during testing or inadvertently in production systems configured for verbose output. The persistence of cleartext credentials in terminal history files such as .bash_history or .zsh_history further extends the window of exposure beyond immediate log analysis to long-term storage artifacts that may be backed up or transferred across systems. This increases the risk of lateral movement if an attacker compromises a system where these logs are retained and accessible by multiple users or services.
Mitigation strategies primarily involve upgrading the openssl-encrypt package to version 1.4.9 or later, which resolves this sanitization deficiency in the debug argument parser. For organizations unable to immediately patch due to dependency constraints, temporary mitigations include disabling debug logging modes in any environment where sensitive keyserver operations are performed and ensuring that log rotation policies aggressively purge stderr outputs containing potential secrets. Additionally, implementing strict access controls on log directories and terminal history files can reduce the blast radius if such information is inadvertently exposed. Regular auditing of application logs for patterns resembling authentication tokens or API keys is also recommended to detect any prior instances where this vulnerability may have been exploited in unpatched environments.