OpenEXR EUVD-2026-65182

The vulnerable code path activates only when an EXR file uses HTJ2K (High Throughput JPEG 2000) compression and contains a QCD marker segment whose lower five bits are all zero - an invalid but syntactically legal value that OpenEXR passes into OpenJPH without validation. No authentication is required and no non-default configuration is needed; the sole prerequisite is that the target application calls exr_start_read() on attacker-controlled input. Applications that only handle EXR files compressed with non-HTJ2K codecs (ZIP, PIZ, RLE, DWAB, etc.) are not exposed to this specific code path. Exploitation is bounded to OpenEXR versions 3.4.0-3.4.12; applications linked against earlier or later versions are unaffected.

The provided CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N) scores zero availability impact despite the vulnerability being a confirmed unconditional process abort; it appears to be a data-entry placeholder and should not be relied upon for prioritization. An independently assessed vector of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (CVSS 7.5 High) better reflects actual impact. Attack conditions are highly favorable: no authentication, no non-default configuration, and any EXR-reading application that accepts external files is exposed. EPSS data was not provided, so exploitation probability cannot be quantified from that source; the absence of KEV listing and public POC moderates urgency. The real-world risk concentrates in automated rendering farms, media ingest microservices, and image-processing pipelines that accept user-supplied EXR files - a single crafted file crashes a worker process, and without supervised restart this can become a sustained outage. For general enterprise environments where OpenEXR is not deployed, exposure is effectively zero; within VFX, broadcast, and game-development infrastructure, this should be treated as a prioritized patch given the trivial triggering condition and the complete absence of any runtime interception path.

An attacker submits a crafted EXR file with a syntactically valid but semantically invalid HTJ2K QCD marker - lower five bits all zero - to a media ingest endpoint, rendering job queue, or image-preview service backed by OpenEXR 3.4.0-3.4.12. When the service calls exr_start_read() on the file, OpenJPH fires an assert() that resolves to abort(), immediately terminating the worker process. No public proof-of-concept has been identified at time of analysis, but the triggering condition is precisely specified in the advisory, making independent reproduction straightforward for any researcher familiar with the JPEG 2000 marker format.