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
Remote and unauthenticated, but AC:H because exploitation requires obtaining 16 specific private-key bytes plus a KEM failure; impact is confidentiality loss of decrypted data, with no direct integrity or availability effect.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
3DescriptionCVE.org
openssl_encrypt versions before 1.4.0 contain a critical vulnerability in pqc.py where KEM decapsulation failures silently fall back to simulation mode, generating a deterministic shared secret from only 16 bytes of the private key and publicly available encapsulated key data. Attackers who obtain 16 bytes of the private key can compute the shared secret and decrypt all ciphertext, as the fallback triggers on any KEM failure without raising an error.
AnalysisAI
Cryptographic shared-secret disclosure in the openssl_encrypt Python library (maintainer 'jahlives') before 1.4.0 lets an attacker reconstruct the KEM shared secret and decrypt all protected ciphertext once they obtain only 16 bytes of the private key. The flaw lives in pqc.py, where any post-quantum KEM decapsulation failure silently falls back to a 'simulation mode' that derives a deterministic secret from those 16 key bytes plus attacker-visible encapsulated-key data, rather than raising an error. Reported by VulnCheck; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Technical ContextAI
The affected component is pqc.py, which implements post-quantum Key Encapsulation Mechanism (KEM) handling for the openssl_encrypt package (cpe:2.3:a:jahlives:openssl_encrypt). A KEM normally produces a high-entropy shared secret via decapsulation using the full private key; if decapsulation fails it must abort. Here the code instead swallows the failure and enters a fallback 'simulation mode' that deterministically computes the shared secret from just 16 bytes of the private key combined with the publicly transmitted encapsulated key. This maps to CWE-391 (Unchecked Error Condition): the error path is not surfaced, so a security-critical failure degrades silently into a weak, predictable keying operation instead of stopping. Because the encapsulated key is public and only 16 private-key bytes feed the derivation, the effective secret entropy collapses to whatever an attacker can learn about those 16 bytes.
RemediationAI
Vendor-released patch: upgrade openssl_encrypt to version 1.4.0 or later, which is the primary and complete fix per GHSA-p3gq-pcg9-qvfv. Until you can upgrade, treat any data encrypted by an affected version as potentially compromised and re-encrypt it after updating, since the weak deterministic secret may already have been used. If immediate upgrade is not possible, the practical compensating control is to verify at the application level that KEM decapsulation actually succeeded and hard-fail (raise/abort) on any KEM error rather than accepting the produced secret - this eliminates the silent simulation-mode fallback but requires code changes and will cause previously 'succeeding' misconfigured deployments to start failing loudly, which is the intended safe behavior. Also rotate the affected private keys, because the design leaks security through partial (16-byte) key exposure. Advisories: https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-p3gq-pcg9-qvfv and https://www.vulncheck.com/advisories/openssl-encrypt-before-weak-shared-secret-via-pqc-simulation-mode.
More in Openssl Encrypt
View allArbitrary native code execution in the jahlives openssl_encrypt Python package (all versions before 1.4.0) arises from i
Fingerprint-verification spoofing in jahlives openssl_encrypt before 1.4.9 lets attackers embed ANSI escape sequences in
Sandbox escape in the openssl_encrypt Python library (jahlives) before 1.4.0 allows attacker-supplied plugins to run wit
Arbitrary code execution in jahlives openssl_encrypt before 1.4.0 stems from an inconsistent sandbox: the runtime Plugin
Authentication bypass in the jahlives openssl_encrypt library (all versions before 1.4.0) lets remote unauthenticated at
Authentication brute-force protection can be bypassed in jahlives openssl_encrypt before 1.4.0 because the TOTP rate lim
Sandbox escape in the openssl_encrypt Python library (jahlives) before 1.4.0 lets attacker-supplied plugin code break ou
Sandbox escape leading to remote code execution affects openssl_encrypt (the jahlives Python package) in all versions be
Arbitrary code execution in openssl_encrypt (the jahlives Python encryption utility) before 1.4.9 allows an attacker-sup
Arbitrary code execution in jahlives openssl_encrypt before 1.4.9 stems from a flawed plugin trust model that uses a den
Sensitive-token exposure in openssl_encrypt (the jahlives Python package, pip 'openssl-encrypt') before 1.4.0 stems from
Arbitrary command execution in jahlives' openssl_encrypt before 1.4.9 arises when the tool's 'info' command reconstructs
Same weakness CWE-391 – Unchecked Error Condition
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-60117
GHSA-7qj7-jv8m-rfjw