openssl_encrypt EUVD-2026-67043

The target application must use jahlives/openssl_encrypt before 1.4.9 and must expose an endpoint that accepts and attempts to decrypt or process attacker-supplied encrypted files without first sanitizing the KDF iteration count in the file's metadata. No authentication is required (CVSS PR:N), no user interaction is needed (UI:N), and no special network position is required beyond being able to submit a file to the service (AV:N/AC:L). Exploitation is limited by: the library must actually be invoked on the submitted file (passive storage without decryption is not exploitable); and the impact is constrained to CPU exhaustion on the decrypting process rather than data disclosure or remote code execution. Deployments that only encrypt files and never decrypt attacker-supplied input are not exposed.

The provided CVSS 4.0 score of 8.7 warrants scrutiny: the vector as supplied lists VC:H (high confidentiality impact) but the CVE description and CWE-400 tag describe a pure resource-exhaustion DoS with no data disclosure component. This appears to be a scoring error in the source data - the true impact is availability, not confidentiality. Correcting for this, the vulnerability is best characterized as a high-severity DoS: network-accessible, requiring no authentication, no user interaction, and no special attack prerequisites per the AC:L/AT:N metrics. The practical barrier to exploitation is extremely low - any service endpoint that accepts encrypted files from untrusted users is directly exposed. There is no CISA KEV listing and no identified public exploit code, so opportunistic mass exploitation is not currently evidenced, but the mechanistic simplicity of the attack (submit a file with a large integer in a metadata field) means weaponization is trivial once an attacker is aware of the flaw. The library is niche, which limits aggregate blast radius, but any deployment processing untrusted encrypted file uploads should treat this as high priority.

An attacker submits a crafted encrypted file to any publicly accessible endpoint - such as a file upload form or API - backed by an unpatched openssl_encrypt deployment. The metadata field controlling KDF iteration count is set to a value near the 64-bit integer maximum. The server begins key derivation synchronously, consuming 100% of a CPU core for minutes or hours, blocking all subsequent processing on that thread and potentially causing service timeouts across the application.