CVE-2026-74876 in openssl_encrypt
Summary
by MITRE • 08/17/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The cryptographic library OpenSSL_encrypt version 1.4.0 and earlier contains a critical security flaw within the PublicKeyBundle.from_dict method that fundamentally compromises the integrity of key management operations. This vulnerability arises from an insufficient validation mechanism when instantiating public key bundles from serialized dictionary data structures provided by external or untrusted sources. In secure cryptographic implementations, any transformation of raw data into active cryptographic keys must include rigorous verification steps to ensure the authenticity and integrity of the underlying material. However, in this specific implementation, the from_dict function proceeds directly with constructing the PublicKeyBundle object without performing signature verification on the input data. This oversight creates a significant trust boundary violation where the application implicitly trusts that the serialized key bundle originates from a legitimate source and has not been tampered with during transmission or storage.
The operational impact of this flaw is severe, as it allows an attacker to inject malicious public keys into the system's cryptographic context. By exploiting the lack of signature verification in PublicKeyBundle.from_dict(), an adversary can supply crafted dictionary data containing their own controlled public key material. When this unverified bundle is subsequently passed through the to_identity method, the library accepts these attacker-controlled keys as valid for encryption operations. Consequently, any sensitive information encrypted using this compromised identity will be secured with a public key known exclusively to the attacker. This effectively neutralizes confidentiality protections, leading to the direct leakage of secrets and potentially exposing critical application data such as session tokens, personal identifiable information, or proprietary business logic to unauthorized parties who possess the corresponding private keys for the injected public keys.
This vulnerability aligns closely with CWE-345 Insufficient Verification of Data Authenticity, which describes scenarios where software does not verify that received data matches expected properties before processing it. Furthermore, from a tactical perspective related to the MITRE ATT&CK framework, this flaw facilitates Initial Access and Credential Access techniques by allowing attackers to intercept or manipulate encrypted communications if they can influence the key selection process during encryption setup. The exploitation chain typically involves crafting malicious input payloads that mimic valid public key bundles but contain attacker-controlled parameters, leveraging the application's trust in serialized data formats without cryptographic proof of origin.
To mitigate this vulnerability, developers must immediately upgrade OpenSSL_encrypt to version 1.4.0 or later where these validation checks have been implemented. For systems unable to update immediately due to compatibility constraints, a temporary workaround involves implementing manual signature verification logic before invoking PublicKeyBundle.from_dict(). This custom validation layer should verify the cryptographic signatures associated with any incoming key bundle data against trusted root certificates or known public keys prior to instantiation. Additionally, input sanitization practices should be enforced to ensure that only expected and validated data structures are processed by cryptographic functions. Regular security audits focusing on serialization and deserialization processes in cryptographic modules can help identify similar weaknesses where implicit trust assumptions might lead to compromise of confidentiality and integrity guarantees.