openssl_encrypt EUVD-2026-67058

Exploitation requires the attacker to substitute public keys inside an identity store loaded from identity.json - that is, the ability to modify, replace, or supply the identity.json file that the victim's openssl_encrypt instance loads. The specific enabling condition is that vulnerable versions (before 1.4.9) do not re-derive and validate the fingerprint on load, so a swapped key that keeps the original claimed fingerprint is accepted silently. Exploitation is limited by the need to reach the identity store: environments where identity.json is a local file writable only by a trusted user are far harder to attack than those where the store is shared, network-synced, or fetched from an untrusted source. There is no user interaction beyond normal identity loading and no authentication to the library itself required by design.

The published CVSS 4.0 score of 9.3 with vector AV:N/AC:L/PR:N/UI:N/VC:H/VI:H/VA:H reflects a worst-case, network-unauthenticated framing, but the concrete prerequisite - the ability to modify or supply a malicious identity.json - is not clearly a pure remote-no-privilege condition, so the network/no-privilege metrics likely overstate reachability for typical local-file identity stores; verify the deployment's identity-distribution model with the vendor. I also disagree with the availability impact (VA:H): this is a confidentiality/integrity trust-bypass, not a denial-of-service, so availability impact is realistically none. There is no EPSS score, no CISA KEV listing, and no evidence of a public proof-of-concept in the provided data, indicating this is currently a high-severity design flaw rather than a demonstrated mass-exploitation event. The real-world danger is high where the identity store is shared, synced, or fetched over an untrusted channel, because exploitation is silent and defeats the very fingerprint check operators rely on to detect tampering.

An attacker gains write access to (or controls the distribution of) a victim's identity.json and replaces a legitimate contact's public key with their own, leaving the stored fingerprint unchanged. The victim's openssl_encrypt then encrypts sensitive data to the attacker's key and validates attacker-forged signatures as genuine, all without any warning. No public proof-of-concept is currently identified, but the technique is straightforward given control of the identity store.