Description

openssl-encrypt before 1.4.9 fails to redact the file password in its --debug argv dump when the password is supplied via bundled short-option spellings (e.g. -apHunter2) or abbreviated long-option spellings (e.g. --passw). The sanitizer only recognized exact option names, --option=value forms, and tokens starting with -p, so these spellings bypass the redaction chokepoint and the cleartext password is written to stderr. Anyone with access to that output (terminal scrollback, merged 2>&1 output, CI job logs, or the GUI's persistent debug log) can recover the password.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-27T17:21:01.147Z",
  "pubdate": "2026-08-27T17:21:01.147Z",
  "executiveSummary": "The openssl-encrypt package before version 1.4.9 contains a critical information disclosure vulnerability within its debugging functionality. The application's command-line argument parser fails to properly sanitize sensitive password inputs when utilizing non-standard option formats. Specifically, the redaction mechanism only accounts for exact long-option matches, '--option=value' assignments, and tokens starting with the '-p' prefix. Consequently, if a user provides a password via bundled short-options (e.g., -apHunter2) or abbreviated long-options (e.g., --passw), the cleartext password is inadvertently printed to stderr when --debug is enabled. This exposure poses a significant risk to confidentiality, as any entity with access to terminal scrollback, redirected log files, or CI/CD output artifacts can trivially extract credentials. The vulnerability is local in nature, requiring an attacker to have access to execution logs or persistent debugging output, which often inadvertently exist in multi-user environments or automated integration pipelines.",
  "technicalDetails": "The root cause of this vulnerability lies in an overly restrictive and non-exhaustive input sanitization logic implemented within the argument processing routine of openssl-encrypt. The application utilizes a flawed filtering mechanism that attempts to redact sensitive arguments before they are output to stderr during debug operations. The existing implementation relies on a brittle pattern-matching approach that exclusively targets specific, canonical command-line syntax: explicit full-length options, key-value pair assignments (e.g., --option=value), and legacy flags starting with the '-p' character.\nThis logic fails to account for standard POSIX-compliant argument bundling and common CLI shorthand practices. When an attacker or a user executes the application using bundled short-options, such as '-apHunter2', the parser fails to identify 'Hunter2' as a sensitive credential component. Similarly, the use of truncated or abbreviated long-option spellings—such as '--passw'—circumvents the pattern-matching regex or logic gate designed to trigger the redaction routine. Because the input does not match the hardcoded allowlist or pattern set, the 'debug' function treats the entire argument string as benign operational data.\nThe attack flow follows a predictable sequence: First, the user executes openssl-encrypt with the --debug flag enabled. Second, the user supplies a password using an unsupported or non-canonical format (bundled '-a' and '-p' or truncated long-options). Third, the command parser processes these arguments, fails the regex/filter check for sensitive data, and passes the raw argv array to the diagnostic logging function. Finally, the application writes the full command line, containing the cleartext password, to stderr. The impact is significant in environments where stderr is persisted, such as CI/CD job logs, shared terminal buffers, or log aggregation systems. Any user, process, or malicious actor with read access to these log files or stdout/stderr streams can recover the plaintext password without further exploitation requirements, effectively bypassing the intended security controls for credential masking."
}