Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain physical write access to USB drive
-
DeliveryAdd unmanifested root-level autorun payload
-
ExploitIntegrity check passes (manifest-only verification)
-
ExecutionVictim mounts and runs drive
-
ImpactPayload executes / offline salt attack recovers key
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Signature verification
|
| Exploitation Conditions | Requires physical write access to an openssl-encrypt portable USB drive (the feature's own untrusted-drive threat model). Integrity-bypass/autorun path: the attacker adds files not present in the drive manifest - including a root-level autorun payload - and the victim must subsequently mount and use the drive for the payload to execute, so victim interaction limits this path. Key-recovery path: the target drive must lack a per-drive salt file, causing the constant _LEGACY_FIXED_SALT to be used, which enables offline rainbow-table precomputation without any victim interaction. Affected only in openssl-encrypt before 1.4.9 and only for drives handled by the portable USB drive feature; drives already carrying a unique per-drive salt are not exposed to the salt weakness. Note the published CVSS AV:N does not match these physical/local prerequisites. |
| Impact | The published CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N, VC:H/VI:H/VA:H, base 9.3 Critical) conflicts sharply with the stated threat model: the description explicitly requires an attacker with PHYSICAL write access to a removable drive, which is AV:P - not the network vector (AV:N) the score claims. This discrepancy should be verified with the vendor, and the raw 9.3 almost certainly overstates real-world risk. Adjusting for the physical prerequisite and, for the code-execution path, the need for a victim to mount and run the drive, practical severity is more moderate. No EPSS score, KEV listing, or POC was provided; there is no public exploit identified at time of analysis and no evidence of active exploitation. Net assessment: a legitimate cryptographic weakness worth patching, but gated behind physical access to a niche tool's USB drives, making it a low-urgency, targeted-scenario issue rather than a broadly wormable network threat. |
| Exploit ScenarioDerived | An attacker who gains temporary physical access to a target's openssl-encrypt portable USB drive writes a malicious root-level autorun payload plus files not listed in the drive manifest; integrity verification passes because it only checks manifest entries, and when the victim later plugs in and uses the drive the payload runs. In parallel, because a drive without a per-drive salt uses the constant _LEGACY_FIXED_SALT, the attacker can precompute a rainbow table offline to recover the drive key and decrypt its contents. No public POC was provided, so exploitation requires the attacker to develop the technique. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 27, 2026
Cryptographic integrity bypass and weak key derivation in the openssl-encrypt Python package (jahlives) before 1.4.9 let an attacker with physical write access to a portable USB drive plant an undetected root-level autorun payload and precompute the drive encryption key offline. The integrity verifier only checks manifest-listed files, so added files pass verification, while a hard-coded fallback KDF salt (_LEGACY_FIXED_SALT) enables an offline rainbow-table attack against drives lacking a per-drive salt. No public exploit identified at time of analysis, and it is not listed in CISA KEV.
RemediationAI
Vendor-released patch: upgrade openssl-encrypt to version 1.4.9 or later (pip install --upgrade openssl-encrypt), the primary and authoritative fix per advisory GHSA-8jx3-27qf-3p97. Until upgraded, treat drives created by vulnerable versions as untrusted: re-create/re-encrypt them after upgrading so a per-drive random salt replaces the constant _LEGACY_FIXED_SALT, and do not rely on _verify_integrity_file output as proof a drive is unmodified. As compensating controls, disable or avoid the portable USB drive feature where feasible, and mount portable drives with noexec/no-autorun so any planted root-level autorun payload cannot execute (trade-off: legitimate on-drive executables also will not auto-run); enforce physical custody of the drives since the entire threat model assumes an attacker with physical write access. Verify affected-version and fix details against the VulnCheck advisory (https://www.vulncheck.com/advisories/openssl-encrypt-before-1.4.9-integrity-bypass-via-added-files).
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
openssl-encrypt is a Python (pip) file-encryption utility whose 'portable USB drive' feature is built around a threat model where the removable drive itself is untrusted. Two flaws undermine that model. First, USBDriveCreator._verify_integrity_file iterates only over entries recorded in the drive manifest, so any file placed on the drive but absent from the manifest - such as a root-level autorun payload - is never hashed or checked, and verification still returns success (CWE-347, improper verification of cryptographic signature/integrity). Second, when a drive has no per-drive salt file, the code derives the drive key using a globally constant, source-embedded value (_LEGACY_FIXED_SALT); because the salt is identical across all such drives and publicly recoverable from source, it removes the per-target uniqueness a KDF salt is meant to provide, enabling attacker precomputation. The affected component is the openssl_encrypt code identified by CPE cpe:2.3:a:jahlives:openssl_encrypt:*.
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
Threat model requires physical write access to the drive (AV:P) and, for the code-execution path, victim use of the drive (UI:R); high confidentiality from offline key recovery and high integrity/availability from the planted payload.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
openssl_encrypt (pip package openssl-encrypt) before 1.4.9 contains two weaknesses in the portable USB drive feature, whose threat model treats the removable drive as untrusted (attacker with physical write access). USBDriveCreator._verify_integrity_file only validates files listed in the manifest, so files added to the drive - including a root-level autorun payload - are not detected and integrity verification still passes. Additionally, a globally constant, source-embedded KDF salt (_LEGACY_FIXED_SALT) is used to derive the drive encryption key for any drive lacking a per-drive salt file, defeating precomputation resistance and enabling an offline rainbow-table attack.
Articles & Coverage 2
Executive ViewAI
The openssl-encrypt Python package (versions before 1.4.9) contains critical flaws in encryption key derivation and integrity verification that enable attackers with physical USB access to inject undetectable root-level malware and decrypt protected data offline. Any organization using this library to protect portable media faces complete compromise without evidence of tampering. Immediate action is required as no vendor patch is currently available.
No vendor-released patch identified at time of analysis. Interim mitigations: (1) Restrict physical access to all portable media in secured facilities; (2) Disable USB autorun and device write access on systems accessing affected drives; (3) Migrate to alternative cryptography libraries maintained by established security teams; (4) Implement mandatory code signing and integrity verification for any scripts or executables from USB media; (5) Monitor system logs for unexpected root-level processes or autorun execution; (6) Establish airgapped environments to prevent lateral movement if compromise is suspected.
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-67067
GHSA-4pgx-8hjp-cmmq
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB