openssl_encrypt EUVD-2026-67036

The attacker must be able to obtain and write back a modified copy of an openssl_encrypt envelope-format file (version below 1.4.9) that actually contains one or more recovery slots - that is the concrete prerequisite. No encryption key, password, or authentication is needed because the recovery-slot header fields are not cryptographically verified, which is the essence of the flaw. What limits exploitation: it only affects the envelope format (not other output modes), the targeted file must contain recovery slots for there to be anything to strip, the attacker needs read/write access to the file itself rather than merely network reachability to a service, and the impact is confined to destroying recovery paths - the primary key still decrypts the payload, so this does not itself disclose plaintext.

Signals here are mixed and should be read carefully. The supplied CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N, VC:H/VI:H/VA:H = 9.3) treats this as a full confidentiality, integrity, and availability breach, but the description supports mainly an integrity impact: the attacker removes recovery slots but does not decrypt or disclose the payload, so the VC:H (high confidentiality) rating looks inflated relative to the described behaviour - verify with the vendor advisory. Real exploitation prerequisites are also stronger than PR:N suggests, since the attacker must be able to obtain and rewrite the target encrypted file, which is closer to a local/data-in-transit tampering scenario than fully remote unauthenticated access. On exploitation maturity, there is no public exploit identified at time of analysis, no CISA KEV listing, and no EPSS probability was provided, so this is a high-CVSS finding without evidence of active or widespread exploitation. The mitigating counterweight is prevalence: openssl_encrypt is an obscure single-maintainer tool, so even an organisation running a small deployment should patch, but the blast radius across typical enterprise fleets is minimal. Net assessment: genuinely serious for the specific users who rely on recovery slots for key-loss resilience, but not a broad emergency for most environments.

An attacker who can read and rewrite a victim's envelope-format encrypted file (for example on shared storage, a backup share, or a file in transit) opens the header, deletes the recovery-slot fields, and saves the file back. The tool accepts the modified file as valid because the header is not authenticated, so the owner's deliberately added recovery key can no longer decrypt the payload and the change is invisible until recovery is attempted. No exploit code is publicly identified at time of analysis, but the manipulation requires no cryptographic keys and only low attack complexity.