CVE-2026-81702 in openssl_encrypt
Summary
by MITRE • 08/27/2026
openssl_encrypt before 1.4.9 fails to re-derive and validate fingerprints when loading identities from identity.json, allowing attackers to substitute public keys in identity stores. Attackers can replace legitimate public keys with their own while maintaining the claimed fingerprint, enabling silent key substitution where encryption uses attacker keys and signature verification appears valid.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in openssl_encrypt prior to version 1.4.9 represents a critical failure in cryptographic integrity validation during the identity loading process. Specifically, when the application reads identities from an identity.json file, it fails to re-derive and validate the associated fingerprints against the actual public keys present in that store. This oversight creates a significant gap between the claimed identity metadata and the underlying cryptographic material, allowing for silent key substitution attacks where the integrity of the encryption pipeline is compromised without triggering standard validation errors.
In normal operation, digital identities rely on the principle that a fingerprint serves as a unique, immutable hash derived from the public key itself. This mechanism ensures that any alteration to the public key results in a mismatched fingerprint, thereby alerting the system or user to potential tampering. However, due to this implementation flaw, the software does not perform this critical verification step upon loading identities. Consequently, an attacker who gains write access to the identity.json file can replace legitimate public keys with their own maliciously generated keys while manually adjusting or retaining the original fingerprint values within the configuration data. The system accepts these modified entries as valid because it trusts the stored fingerprint without cross-referencing it against the actual key material being loaded into memory for cryptographic operations.
The operational impact of this vulnerability is severe, particularly in systems relying on mutual authentication and encrypted communications. By substituting public keys while maintaining the claimed fingerprint, an attacker can position themselves as a man-in-the-middle or impersonate legitimate entities within the trust chain. Encryption processes will utilize the attacker's private key to decrypt data intended for the original owner, effectively breaking confidentiality. Simultaneously, signature verification mechanisms may appear valid because they rely on the public keys loaded from the compromised store. Since the system believes it is using the correct identity based on the unvalidated fingerprint, signatures created by the attacker with their corresponding private key will pass validation checks against the substituted public key, leading to a false sense of security and integrity for all downstream processes that trust these identities.
This flaw aligns closely with CWE-345 Insufficient Verification of Data Authenticity, as the system fails to ensure data consistency between related components (the fingerprint and the public key). It also relates to CWE-295 Improper Certificate Validation, specifically regarding the failure to validate certificate or identity properties against their underlying cryptographic material. From an ATT&CK perspective, this vulnerability facilitates techniques associated with T1078 Valid Accounts and potentially T1463 Single Sign-On, as it allows attackers to hijack trusted identities without detection by standard authentication logs that rely on fingerprint matching rather than deep key validation.
To mitigate this risk, organizations must immediately upgrade openssl_encrypt to version 1.4.9 or later where the identity loading logic has been corrected to enforce strict fingerprint-key binding verification. Until an update is applied, administrators should implement rigorous file integrity monitoring for identity.json files and restrict write access to these configuration stores using least-privilege principles. Additionally, implementing out-of-band validation mechanisms that independently verify public keys against known good fingerprints can provide a secondary layer of defense. Security teams should also audit existing logs for anomalies in key usage patterns that might indicate active exploitation of this silent substitution capability before the patch is deployed.