openssl-encrypt CVE-2026-81694

Exploitation requires all of the following concrete conditions: (1) the attacker can control filenames on a drive that the victim will scan - these names live outside the AES-GCM authenticated manifest and are not integrity-protected; (2) the victim runs the specific verify-usb command of openssl-encrypt version <= 1.4.8 against that attacker-influenced drive; and (3) the victim views the command's output in a terminal emulator that interprets ANSI/VT100 cursor-movement and erase-line control bytes. Limiting factors: the attack is a display-spoofing deception only (no code execution, no data disclosure), it depends on the victim actively running verify-usb and reading interactive terminal output, and it fails if output is captured to a plain log, piped through a control-character sanitizer, or viewed in a non-interpreting viewer. Despite the provided vector's PR:N/UI:N, the described mechanics imply attacker-supplied drive data plus victim action, so the practical prerequisites are narrower than a remote unauthenticated attack.

The supplied CVSS 4.0 score of 9.3 (VC:H/VI:H/VA:H, AV:N) substantially overstates the real technical impact of this bug and should be treated with caution. The actual weakness is CWE-117 output injection whose sole effect is to repaint a forged verdict on a terminal - there is no confidentiality loss, no availability loss, and no code execution, so high C/I/A ratings are not supported by the description. The 'AV:N/PR:N/UI:N' portion of the vector also conflicts with the described mechanics: exploitation requires the victim to run verify-usb against attacker-supplied drive data and to view the result in an escape-sequence-interpreting terminal, which is closer to local delivery with user interaction than to remote unauthenticated attack - verify with the vendor. There is no CISA KEV listing, no EPSS value supplied, and no POC referenced, so this is a low-probability, targeted deception scenario rather than a mass-exploitation threat. That said, the consequence class matters for anyone who relies on verify-usb as a security control: a spoofed PASSED verdict could cause an operator to trust a tampered drive, so teams using this tool for integrity attestation should still patch promptly even though the raw 9.3 headline number overstates the danger. Net assessment: high-severity-on-paper, moderate-real-risk, narrow prerequisites.

An attacker prepares a USB drive (or other removable medium) whose files carry names embedding terminal cursor-movement and erase-line escape sequences alongside real tampering of the drive's contents. When a victim runs 'verify-usb' on that drive with a version <= 1.4.8, the tool's genuine tamper-detection output is visually overwritten by a forged 'PASSED' line, so the operator accepts a compromised drive as authentic. No public POC is referenced, and exploitation depends on local delivery of the malicious drive plus the victim viewing output in an ANSI-interpreting terminal.