OpenEXR patches HTJ2K decoder overflow with potential code execution

TL;DR — A crafted HTJ2K-compressed .exr image can trigger a heap buffer overflow in OpenEXR’s decoder, potentially leading to code execution in any app that decodes untrusted EXR files.

What happened

OpenEXR is a widely used, open-source image file format and reference implementation commonly embedded in creative tools, render pipelines, and asset ingestion services.

CVE-2026-34545 reports a High-severity integer-overflow-driven heap buffer overflow in the HTJ2K decode path affecting openexr versions >= 3.4.0, < 3.4.7. The CVE record describes a crafted .exr file (HTJ2K compression, channel width 32768) that can cause controlled writes beyond the output heap buffer in applications that decode EXR images, with the write primitive repeating for each pixel past the overflow point.

The associated GitHub advisory (GHSA-ghfj-fx47-wg97) attributes the bug to a type mismatch where an int16_t loop counter overflows while the channel width is stored as int32_t and not bounded, resulting in both out-of-bounds reads and out-of-bounds writes in the decoder loop.

File-parsing memory corruption in “shared” codec/format libraries tends to have cross-product blast radius: a single vulnerable decoder can sit behind many different desktop tools and server-side pipelines that ingest untrusted media.

Who is impacted

• Projects that link or bundle openexr and decode HTJ2K-compressed EXR content, including via transitive dependencies.
• Applications using openexr versions >= 3.4.0, < 3.4.7 (per the CVE record).

What to do now

• Follow vendor remediation guidance and apply the patched release.

  • "This issue has been patched in version 3.4.7."

• Inventory where EXR decoding happens in your environment (desktop apps, render workers, preview services, CI asset pipelines) and identify whether any deployment path processes EXR files from untrusted sources.
• Treat EXR ingestion as an attack surface:
  • Prefer isolating decoders behind sandboxing / least-privilege execution where feasible.
  • If compromise is suspected, review recent EXR ingestion inputs and crash telemetry around decode operations, and rotate credentials available to any affected worker/service accounts.