OpenEXR CVE-2026-53532

The vulnerability requires that an application call exr_start_read() on attacker-controlled EXR data encoded with HTJ2K compression where the QCD marker has its lower five bits set to zero. CVSS PR:N confirms no authentication is required to deliver the crafted file to an exposed ingestion endpoint. CVSS UI:P indicates at least one user or process action is required to open the file, though in automated processing pipelines (render farms, DAM ingest workers, thumbnail services) this condition is effectively eliminated. Exploitation is strictly bounded to denial of service - there is no code execution, memory disclosure, or privilege escalation pathway. The vulnerability is version-bounded to OpenEXR 3.4.0-3.4.12; prior versions lacking HTJ2K support and version 3.4.13 onward are not affected. No special operating system, platform, or configuration is required beyond having a vulnerable OpenEXR version linked into the processing application.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N, score 7.1) accurately reflects a remotely triggerable, low-complexity denial of service requiring only that a user or automated process open the crafted file (UI:P). The impact is strictly limited to availability - no confidentiality or integrity exposure exists. The vulnerability does not appear in the CISA KEV catalog and no public exploit code was identified in available intelligence, so exploitation is currently unconfirmed; however, the trigger condition is precisely documented in the CVE description, making independent reproduction straightforward. EPSS data was not provided in the available intelligence sources, leaving probabilistic exploitation likelihood unquantified. The practical risk is heavily context-dependent: automated media ingest pipelines, digital asset management systems, and VFX render farms that accept externally sourced EXR files effectively eliminate the UI:P friction, raising real-world exposure significantly above what the score alone implies. Environments where EXR files originate exclusively from trusted internal sources face minimal risk. The abort()-based crash mechanism is non-recoverable, meaning affected services cannot degrade gracefully and must be restarted, making sustained denial of service trivially achievable through repeated file submission.

An attacker crafts an EXR file using HTJ2K compression with a QCD marker whose lower five bits are all zero, then submits it to a service that calls exr_start_read() - such as a web-based image preview service, a digital asset manager thumbnail generator, or an automated VFX render pipeline job queue. Upon ingestion, OpenJPH's internal assertion fires unconditionally, calling abort() and terminating the host process with no error recovery. If the service is configured to auto-restart, repeated submission of the single crafted file sustains a denial of service condition with minimal attacker effort.