Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain lost or stolen USB media
-
ExploitMount removable device on attacker machine
-
ExecutionRead cleartext 'Encrypted USB Workspace' files
-
ImpactExfiltrate sensitive data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V14 - Data Protection Encryption of sensitive data
|
| Exploitation Conditions | Exploitation requires physical possession of or access to the removable/USB media on which the victim created an openssl_encrypt 'Encrypted USB Workspace' using a vulnerable version (<= 1.4.8), and the victim must have actually used that workspace feature to store files. The limiting factors are significant: the attacker needs the physical device (no remote/network path despite the input's AV:N rating), the victim must have opted into the specific 'Encrypted USB Workspace' feature rather than another encryption mode, and only data placed in that workspace is exposed. There is no user interaction or authentication barrier for the attacker once the media is in hand, and the impact is confidentiality only - the false 'encrypted' marker does not protect the plaintext beneath it. |
| Impact | The signals conflict and must be reconciled. The supplied CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N/VC:H/VI:H/VA:H, score 9.3) models a remote, unauthenticated, full-CIA-impact flaw, but the description clearly requires an attacker with PHYSICAL access to the removable media and yields only confidentiality loss (reading cleartext files). The AV:N and VI:H/VA:H ratings are not supported by the description - verify with the vendor; a physical-access, confidentiality-only assessment is far more defensible (see assessed vectors below). There is no EPSS score, no KEV listing, and no POC provided, so this is not evidence of widespread active exploitation. Real-world risk is a targeted, opportunistic threat: someone who steals, finds, or borrows the USB device gets plaintext, and the danger is amplified because victims believe the data is encrypted and may therefore be less careful with the media. Absolute risk is bounded by the product's niche footprint and the physical-access requirement, not the inflated 9.3. |
| Exploit ScenarioDerived | A user encrypts sensitive documents into what openssl_encrypt labels an 'Encrypted USB Workspace,' sees the marker confirming AES-256-GCM protection, and carries the USB drive with them. The drive is lost or stolen, or briefly left unattended; the attacker plugs it into any machine and reads the files directly because they were never encrypted. No POC is needed and no cryptographic attack is required - the data is simply cleartext. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 27, 2026
Sensitive-file exposure in the openssl-encrypt pip package (openssl_encrypt) at versions <= 1.4.8 stems from its 'Encrypted USB Workspace' feature writing a marker that falsely declares the workspace AES-256-GCM encrypted while the derived key is never applied and the directory remains in cleartext. Users who trust the branding and store files in the workspace leave them fully readable on the removable media, so anyone with physical possession of the USB device can recover the data. No public exploit identified at time of analysis and the flaw is not in CISA KEV, but the failure silently defeats the product's core security promise.
RemediationAI
Vendor-released patch: upgrade to openssl_encrypt 1.4.9 (pip install --upgrade openssl-encrypt), which seals the workspace into an authenticated AES-256-GCM vault so data is genuinely encrypted at rest; this is the primary and complete fix per GHSA-2jv6-qqfm-m46m. Because any workspace created with <= 1.4.8 is already cleartext on the media, patching alone is insufficient - treat all existing 'Encrypted USB Workspace' data as exposed: physically secure or wipe/re-provision those devices, rotate any secrets stored on them, and re-create the workspace under 1.4.9 so encryption is actually applied. As an interim compensating control before upgrading, do not rely on the workspace feature - store sensitive files in an independently verified encryption container (for example OS-level volume encryption such as LUKS, BitLocker To Go, or VeraCrypt on the removable media) and keep physical custody of the USB device; the trade-off is loss of the product's convenience workflow. Verify encryption independently by inspecting raw bytes on the device rather than trusting the in-workspace marker.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected component is jahlives' openssl_encrypt, a Python utility distributed on PyPI as openssl-encrypt (CPE cpe:2.3:a:jahlives:openssl_encrypt). The 'Encrypted USB Workspace' feature is intended to provide an authenticated AES-256-GCM encrypted container on portable/removable media, deriving an encryption key and sealing files at rest. The root cause maps to CWE-311 (Missing Encryption of Sensitive Data): the code advertises encryption and even persists a marker asserting the workspace is encrypted, but never actually applies the derived key to the workspace contents. The result is a trust/labeling mismatch - cryptographic material may be generated, but the plaintext-to-ciphertext transformation of the workspace data is absent, so the security control exists only in branding.
Know when OpenSSL gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
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
Attack needs physical access to the removable media (AV:P) and yields only disclosure of cleartext files (C:H, I:N, A:N); no auth or user interaction for the attacker.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
openssl_encrypt (pip package openssl-encrypt) versions <= 1.4.8 advertise a portable USB workspace as an 'Encrypted USB Workspace' with AES-256-GCM encryption and write a marker declaring the workspace encrypted, but the workspace directory is actually stored in cleartext and the derived encryption key is never applied to it. A user who trusts the branding and places files in the workspace leaves them unencrypted on the removable media, so an attacker with physical access to the media can read the sensitive files. Fixed in 1.4.9, which seals the workspace into an authenticated AES-256-GCM vault.
Articles & Coverage 2
Executive ViewAI
The openssl-encrypt pip package (versions ≤1.4.8) contains a critical flaw in its 'Encrypted USB Workspace' feature: files are stored in cleartext while a false marker claims AES-256-GCM encryption, creating a silent confidentiality breach. Organizations relying on this package for USB data protection face complete loss of encryption assurance; physical access to USB devices exposes all stored data.
No vendor-released patch identified at time of analysis. Interim mitigations: discontinue Encrypted USB Workspace feature immediately; migrate to alternative cryptographic solutions with published security audits; enforce physical security protocols for all USB devices; require air-gapped or non-portable storage for sensitive data; conduct inventory of all USB devices that may contain data encrypted with this tool.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
In order to decrypt SM2 encrypted data an application is expected to call the API function EVP_PKEY_decrypt(). Rated cri
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
In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehas
The TLS protocol 1.2 and earlier, when a DHE_EXPORT ciphersuite is enabled on a server but not on a client, does not pro
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
EUVD-2026-67037
GHSA-c4f3-9gjw-6j6x
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB