OpenEXR CVE-2026-45696

Requires the target application to invoke OpenEXR's standard scanline-decode entry point (exr_decoding_run or Imf::checkOpenEXRFile) on an attacker-supplied EXR file that uses HTJ2K compression and embeds a JPEG 2000 codestream whose declared tile/line width is smaller than the EXR header's channel width. No user interaction beyond the application opening the file is needed; no special OpenEXR configuration is required because HTJ2K is part of the default decoder. Limiting factors: the file must reach a consumer of OpenEXR 3.4.0-3.4.11 specifically (the HTJ2K decoder did not exist in earlier branches), and the bug is a 4-byte over-read so the realistic impact is DoS plus possible small heap disclosure rather than control-flow hijack.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H) emphasizes availability impact with no confidentiality or integrity loss in the vulnerable system, which matches a deterministic crash bug; the SA:H reflects that downstream services parsing user-supplied EXRs (render farms, thumbnail services, asset ingestion) can be taken offline. The PR:L choice is questionable because parsing an untrusted EXR file typically does not require authentication on the OpenEXR library itself - the privilege requirement is really on whatever wrapping service ingests the file, and many real-world consumers (thumbnailers, web asset pipelines) process attacker-controlled input with no auth. No EPSS, KEV, or SSVC data was provided, and no public exploit identified at time of analysis. The description notes a 'potential adjacent-heap leak,' so a memory-disclosure primitive cannot be ruled out, but exploitation beyond DoS is not demonstrated. Net risk: high-priority patch for any pipeline that ingests untrusted EXR files, but practically a DoS/info-leak rather than RCE.

An attacker uploads a crafted EXR file to a service that automatically thumbnails or ingests image assets - for example a media-asset web app, a render-farm submission queue, or a desktop file-manager preview pane. When the worker calls exr_decoding_run or Imf::checkOpenEXRFile on the file, ht_undo_impl() reads 4 bytes past the OpenJPH line buffer, crashing the process and potentially leaking adjacent heap contents into error logs or telemetry. No public exploit identified at time of analysis, but the bug is deterministic and trivially reachable through the default decode path.