OpenEXR CVE-2026-42216

Exploitation requires the target application to parse EXR files containing IDManifest metadata structures, which are part of the standard EXR specification and enabled by default in OpenEXR library builds. The vulnerability triggers when processing specially crafted files where prefix-compressed string sequences include a >255-byte string followed by a truncated <2-byte string-conditions an attacker fully controls through file format manipulation. No special OpenEXR build flags, non-default configuration settings, or specific application features are required beyond standard EXR image decoding. Limiting exploitation: the attacker must deliver the malicious EXR file to the target system (via upload interface, email attachment, network file share, or supply chain insertion), and the target application must invoke OpenEXR parsing on untrusted input. Applications that only process EXR files from authenticated, verified sources have reduced exposure, though not immunity.

CVSS 4.0 score of 8.8 with vector AV:N/AC:L/PR:N/UI:N indicates remote unauthenticated exploitation against default configurations with low attack complexity. The VC:H rating reflects significant confidentiality impact from memory disclosure, while VA:H indicates high availability impact from potential crashes. However, real-world risk depends heavily on deployment context: applications that parse untrusted EXR files from network sources (web image processors, cloud rendering farms, automated asset pipelines) face immediate risk, while isolated workstations processing only trusted artist-generated files have lower exposure. No EPSS score provided, limiting probabilistic risk assessment. No CISA KEV listing and no public exploit identified at time of analysis suggest exploitation remains theoretical rather than widespread. The CVSS vector shows no scope change (SC:N/SI:N/SA:N), meaning the vulnerability does not enable lateral movement beyond the vulnerable component itself. SSVC factors: Exploitation status is 'none' (no public POC), Automatable is 'yes' (requires only file parsing, no user interaction), Technical Impact is 'partial' (confidentiality + availability but not integrity control). Priority depends on whether the deployment exposes EXR parsing to untrusted network inputs-high priority for cloud services and web applications, medium for desktop creative tools with user-controlled file sources.

An attacker crafts a malicious EXR image file with IDManifest metadata containing a string sequence where the first string exceeds 255 bytes, followed by a deliberately truncated string with fewer than two bytes. When a victim application (cloud image transcoder, automated thumbnail generator, visual effects rendering node) parses the file using vulnerable OpenEXR library code, IDManifest::init() reads beyond the allocated string buffer, leaking up to 2 bytes of adjacent heap memory and potentially crashing the service. Leaked memory contents could expose cryptographic keys, session tokens, or other sensitive data from the same process space, while repeated crashes enable denial of service against automated processing pipelines.