Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Attacker-supplied local drive data (AV:L) plus a victim who must run verify-usb and view terminal output (UI:R); impact is defeating the integrity verdict (I:H) with no confidentiality or availability effect.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionCVE.org
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().
Articles & Coverage 2
AnalysisAI
Verdict spoofing in the openssl-encrypt pip package (versions <= 1.4.8) lets an attacker who controls the contents of a scanned drive forge a PASSED tamper-check result. Because filenames read from untrusted drive data are printed by the verify-usb command without neutralizing terminal control bytes, crafted names containing cursor-movement and erase-line sequences can repaint the screen to hide genuine tamper detection. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | 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. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | 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. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | 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. … |
| Remediation | Upgrade to openssl-encrypt 1.4.9 or later, which is the vendor-released patch and neutralizes the issue by passing drive-derived filenames through sanitize_for_display() before printing (pip install --upgrade openssl-encrypt). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory all systems running openssl-encrypt versions 1.4.8 or earlier and halt reliance on verify-usb output until patching is complete. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before
In OpenSSL 1.1.0 before 1.1.0d, if a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this
A denial of service flaw was found in OpenSSL 0.9.8, 1.0.1, 1.0.2 through 1.0.2h, and 1.1.0 in the way the TLS/SSL proto
Same weakness CWE-117 – Improper Output Neutralization for Logs
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-67050
GHSA-9grr-c5h5-3w4h