CVE-2026-81694 in openssl_encrypt
Summary
by MITRE • 08/27/2026
openssl-encrypt (pip package, versions <= 1.4.8) fails to sanitize filenames read from untrusted drive data (outside the AES-GCM authenticated manifest) before printing them in the verify-usb command's output. An attacker can plant filenames containing terminal cursor-movement and erase-line control bytes that repaint a forged PASSED verdict on screen, masking actual tamper detection. Fixed in 1.4.9 by routing drive-derived names through sanitize_for_display().
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The openssl-encrypt utility contains a critical vulnerability related to improper handling of untrusted input data during the verification process for USB drives. Specifically, versions up to and including 1.4.8 fail to properly sanitize filenames extracted from external storage devices before displaying them in the output of the verify-usb command. This flaw arises because the application reads file names directly from the drive's filesystem structure without validating or escaping special control characters that are present within those strings. The security boundary is breached at the point where data moves from an untrusted source, such as a potentially compromised USB drive, into the terminal display layer of the application.
The technical nature of this vulnerability falls under CWE-16: Configuration and CWE-798: Use of Hard-coded Credentials if we consider the trust model, but more accurately it aligns with CWE-20: Improper Input Validation regarding the lack of sanitization before processing for display. The core issue is that filenames containing ANSI escape sequences or other terminal control codes are passed directly to the standard output stream without filtering. These control bytes include characters used for cursor movement, such as moving the cursor up, down, left, or right, and commands for erasing lines on the screen. Because modern terminals interpret these sequences as instructions rather than literal text, an attacker can embed malicious formatting codes within a file name to manipulate how the terminal renders subsequent output.
The operational impact of this vulnerability is severe due to its potential for visual deception in security-critical workflows. An adversary who has physical access to create or modify files on a USB drive can craft filenames that contain specific control sequences designed to repaint parts of the screen after the application prints its verification status. For instance, an attacker could place a file with a name containing escape codes that move the cursor back to previous lines and overwrite them with forged text indicating PASSED when the actual integrity check has failed or detected tampering. This technique effectively masks the true state of the drive's security posture from the user relying on the tool for verification purposes, leading to false confidence in compromised data.
This behavior is analogous to terminal injection attacks described in various industry frameworks and can be mapped to ATT&CK techniques involving command-and-control channel manipulation or defense evasion through visual obfuscation. While not a direct code execution vector like buffer overflows, it represents a significant risk for integrity verification tools where the output itself serves as the primary indicator of trustworthiness. Users who rely on this tool to verify the authenticity and integrity of bootable media or sensitive data storage devices may be misled into believing that their system is secure when it has actually been tampered with by an attacker leveraging physical access capabilities.
The vulnerability was addressed in version 1.4.9 through a code change that routes all drive-derived file names through a dedicated sanitization function named sanitize_for_display(). This fix ensures that any special characters, including ANSI escape sequences and other control bytes, are either stripped out or escaped before being sent to the terminal output stream. By implementing this input validation step at the presentation layer, the application prevents malicious formatting codes from influencing the visual representation of the verification results.
To mitigate similar risks in related applications, developers should ensure that all data originating from untrusted external sources is strictly validated and sanitized before rendering it on a user interface or terminal output. This includes filtering out non-printable characters and escape sequences unless they are explicitly required for legitimate formatting purposes which must be carefully controlled. Security audits of verification tools should specifically test for visual injection vulnerabilities where the integrity of the displayed status message can be compromised by manipulating input data from external devices. Organizations using this software should immediately upgrade to version 1.4.9 or later to ensure that their USB drive verification processes remain reliable and resistant to such deceptive attacks.