Which versions of openssl_encrypt are affected by CVE-2026-74876?

The openssl_encrypt Python library (versions before 1.4.0) contains a critical vulnerability enabling attackers to decrypt encrypted secrets when applications encrypt data using untrusted key bundles…. A patch is available.

How to fix or mitigate CVE-2026-74876?

Within 24 hours, inventory all applications using openssl_encrypt versions prior to 1.4.0, with particular focus on systems handling financial data, authentication credentials, or personally identifiable information. Within 7 days, update all affected applications to openssl_encrypt 1.4.0 or later and verify deployments across production, staging, and development environments. Within 30 days, conduct a historical audit of encryption operations to determine whether untrusted key bundles may have been used, consult threat intelligence sources to assess if this vulnerability has been exploited against your organization, and implement mandatory key source validation to prevent similar control bypass vulnerabilities.

openssl_encrypt CVE-2026-74876

Q: What is the CVSS score of CVE-2026-74876?

CVE-2026-74876 has a CVSS 4.0 base score of 9.3 (Critical). CVSS vector: 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. EPSS exploitation probability: 0.2%.

EUVD-2026-60095 CRITICAL

Improper Verification of Cryptographic Signature (CWE-347)

2026-08-17 VulnCheck

GHSA-723w-crw6-p9hx

Information Disclosure Jwt Attack Openssl Encrypt Jahlives

9.3

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

9.3 CRITICAL

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

vuln.today AI

7.4 HIGH

AV:N since bundle data can arrive remotely and PR:N as no auth is intrinsic, but AC:H because exploitation requires the app to use the unverified from_dict()->to_identity() path; A:N since impact is secret disclosure/crypto-integrity, not availability.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Aug 17, 2026 - 13:16 vuln.today

Analysis Generated

Aug 17, 2026 - 13:16 vuln.today

Patch available

Aug 17, 2026 - 12:01 EUVD

CVE Published

Aug 17, 2026 - 11:04 cve.org

CRITICAL 9.3

DescriptionCVE.org

openssl_encrypt versions before 1.4.0 contain a vulnerability in PublicKeyBundle.from_dict() that creates key bundles from untrusted data without verifying signatures. Attackers can call from_dict() followed by to_identity() without signature verification to encrypt data using attacker-controlled public keys, leaking secrets.

AnalysisAI

Secret disclosure affects the openssl_encrypt Python library (all versions before 1.4.0), where PublicKeyBundle.from_dict() constructs key bundles from untrusted serialized data without validating the embedded self-signature, and to_identity() then promotes that unverified bundle into a usable Identity. An application that deserializes an attacker-supplied bundle and encrypts to it - without an intervening verify_signature() call - will encrypt secrets to an attacker-controlled public key, allowing the attacker to decrypt them. Reported by VulnCheck and fixed in 1.4.0; no public exploit has been identified at time of analysis.

Technical ContextAI

openssl_encrypt is a pip-distributed Python encryption library (CPE cpe:2.3:a:jahlives:openssl_encrypt) that wraps public-key operations behind serializable key bundles. The root cause is CWE-347 (Improper Verification of Cryptographic Signature): PublicKeyBundle.from_dict() in openssl_encrypt/modules/key_bundle.py (lines 329-361) explicitly documents that it does NOT verify the signature and expects callers to invoke verify_signature() afterward, but to_identity() (lines 363-391) can convert an unverified bundle straight into an Identity with no enforcement. This is a classic 'insecure-by-default API / trust-boundary' flaw: the safe consumer path in key_resolver.py (lines 146-147) does verify before use, but the raw from_dict()->to_identity() sequence remains directly callable, so security depends entirely on downstream discipline rather than on the library enforcing verification.

RemediationAI

Vendor-released patch: upgrade to openssl_encrypt 1.4.0, which fixes the issue in commit f4a1ba6 (branch releases/1.4.x) by making from_dict() verify the self-signature by default via a verify=True parameter and raise ValueError on failure; upgrade with 'pip install --upgrade openssl-encrypt>=1.4.0'. If you cannot upgrade immediately, the concrete compensating control is to never call PublicKeyBundle.from_dict() followed by to_identity() on untrusted data without an explicit verify_signature() check in between - route all bundle handling through the already-safe key_resolver.py path (which verifies at lines 146-147), and treat any deserialized bundle as untrusted until verification succeeds; the trade-off is that this relies on code-review discipline and audit of every call site rather than a library-enforced guarantee, so it is strictly weaker than upgrading. Reference the advisory at https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-8h88-gxp3-j7pg and the fix commit https://github.com/jahlives/openssl_encrypt/commit/f4a1ba660063cd9e17883829e5272a248525a16b.