CVE-2026-81694: verify-usb before 1.4.9 Output Injection via Unsanitized Filenames
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 sanitizefordisplay().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
openssl-encrypt (pip package)to a version that resolves this vulnerability.Fixed in 1.4.9
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Operators using the verify-usb command in openssl-encrypt versions 1.4.8 or earlier are exposed when they verify untrusted drive data and rely on the terminal output to assess the result.
What does an attacker need to exploit it?
An attacker needs to place crafted filenames on drive data that will be processed by verify-usb. The filenames must contain terminal cursor-movement or erase-line control bytes so the displayed verdict can be repainted.
Does this affect the integrity of the authenticated manifest or AES-GCM protection?
The affected filenames are outside the AES-GCM authenticated manifest. The issue is output injection that can mask tamper detection on screen, rather than a stated failure of the authenticated manifest itself.
How can this be remediated?
Upgrade openssl-encrypt to version 1.4.9, which routes drive-derived filenames through sanitize_for_display().