CVE-2026-44663: OpenEXR HTJ2K Integer Overflow & Heap Buffer Overflow (3.4.0–3.4.11)

Technical summary

CVE-2026-44663 stems from an unchecked integer overflow in ht_undo_impl() within src/lib/OpenEXRCore/internal_ht.cpp. The vulnerability occurs when decoding HTJ2K-compressed EXR images: the width field (int32_t) is multiplied by bytes_per_element using 32-bit signed arithmetic without prior bounds validation. With sufficiently large width values (≥536870912 for FLOAT data), this multiplication overflows, producing a negative or truncated result that is subsequently used as a memory offset in pointer arithmetic. This leads to a heap buffer overflow during out-of-bounds writes. The same unchecked pattern appears in two additional HTJ2K code paths responsible for bytes-per-line accumulation and pixel-line pointer advancement, suggesting systemic validation gaps. The fix implemented in 3.4.12 validates dimensions before performing multiplication, preventing overflow conditions.

Business impact

Organizations relying on OpenEXR for visual effects pipelines, animation production, or post-production workflows face denial-of-service risk if attackers distribute malicious EXR files to studios or freelancers. While the CVSS score reflects medium severity, the impact depends on deployment context: isolated rendering farms or VFX workstations processing untrusted content from external sources carry elevated risk. Crash-based denial of service could disrupt rendering deadlines and downstream publishing schedules. The local-attack vector and requirement for user interaction (opening a file) limit exposure in server-only environments but not in creative studios where file sharing is routine.

Affected systems

OpenEXR 3.4.0 through 3.4.11 are vulnerable. The library is the reference implementation for the EXR image format and is embedded in or used by visual effects software, rendering engines, and image processing tools across the motion picture industry. Any system running an affected version and processing EXR files from untrusted or potentially adversarial sources is at risk. Version 3.4.12 and later contain the remediation.

Exploitability

Exploitability is moderate. The attack requires local file access (AV:L) and user interaction to open a malicious EXR file (UI:R), making opportunistic remote exploitation unlikely. However, the bar for crafting a triggering file is low: generating an HTJ2K-compressed EXR with an oversized width value is straightforward. Social engineering (e.g., sharing a 'reference asset' or 'template project') could facilitate delivery. The vulnerability does not require special privileges to trigger. As of the publication date, CVE-2026-44663 is not listed in the CISA Known Exploited Vulnerabilities catalog.

Remediation

Upgrade OpenEXR to version 3.4.12 or later. Organizations should verify the version in use across their VFX pipelines, rendering farms, and any integrated applications. Where immediate patching is not feasible, restrict file opening to trusted internal assets and disable external EXR imports until patching is complete. Code review of HTJ2K-consuming applications is advisable to ensure they perform pre-multiplication validation.

Patch guidance

Update OpenEXR to version 3.4.12 or later. Consult the OpenEXR release notes and your software vendor's compatibility matrix to confirm that dependent applications support the patched version without regressions. Test the patched library in a non-production environment with representative EXR files before rolling out to rendering farms or production workstations. If OpenEXR is vendored or statically linked within another application (e.g., a rendering engine), coordinate with the upstream vendor for an updated release; do not assume automatic inheritance of the fix.

Detection guidance

Monitor for unexpected crashes or allocation failures when processing HTJ2K-compressed EXR files, particularly those with unusually large width or channel counts. Log or alert on any OpenEXR library version checks that report 3.4.0–3.4.11 during software inventory scans. Review recent EXR file ingestion sources and validate file provenance. Fuzzing or regression testing with oversized-dimension test cases can help confirm patch effectiveness post-deployment. Application-level logging of image dimension parameters before decoding can help identify malicious patterns.

Why prioritize this

Assign medium-to-high priority in creative and VFX environments; lower priority in server/rendering-only contexts lacking user interaction. The integer-overflow-to-heap-overflow chain is well-understood, reliable to trigger, and difficult to defend against at the application layer. While CVSS score is 6.1 (MEDIUM), the confluence of direct file-format handling, systemic validation gaps in multiple code paths, and industry prevalence of OpenEXR in supply-chain scenarios warrants prompt patching. Non-KEV status and local-attack vector prevent critical classification, but this should not delay remediation in exposed environments.

Risk score, explained

CVSS 3.1 score of 6.1 (MEDIUM) reflects: AV:L (local file required), AC:L (no special conditions), PR:N (no privileges needed), UI:R (user must open file), S:U (no scope change), C:N (confidentiality not impacted), I:L (integrity low—limited write scope), A:H (availability high—crash likely). The score appropriately captures that an unauthenticated user with file access can reliably crash the application or corrupt heap state, but the local-only vector and user-interaction requirement prevent a higher severity. However, in threat modeling, the lack of confidentiality impact should not minimize the severity of heap corruption, which can enable privilege escalation or code execution under specific memory layout conditions not fully characterized in public analysis.

Frequently asked questions