One Multiply, One Heap Overflow: An Integer Overflow in OpenEXR (CVE-2026-41142)

OpenEXR is the high-dynamic-range image format that most of film and VFX runs on, and it is parsing library code that routinely opens files from untrusted sources. That combination is why a single arithmetic mistake in it matters. I reported an integer overflow here that turns opening one crafted image into a controlled heap write.

What the bug is

An integer overflow (CWE-190) in ImageChannel::resize(), at ImfImageChannel.cpp line 70. When the channel is resized, the code computes the pixel count as _pixelsPerRow multiplied by _pixelsPerColumn, in signed int, before that value is converted to a wider type.

The mechanics

Choose image dimensions whose product exceeds what a 32-bit signed integer can hold, roughly four billion. The multiply overflows. In practice it wraps modulo 2^32, so the running pixel count becomes a small value. The library then allocates a buffer sized for that small, wrong number.

The corruption comes on the next step. The code writes the actual pixel data using the un-truncated stride, the real width of the image. The allocation was sized for the wrapped count, the writes use the true size, and the difference lands on the heap past the end of the buffer. A crafted file gets to place attacker-shaped bytes into adjacent heap memory. Confidentiality, integrity and availability are all rated high because a controlled out-of-bounds write is a strong primitive to build on.

Impact and conditions

The attack vector is opening a file. There is no privileged access required and no unusual configuration. Any process that ingests untrusted EXR files, a thumbnail generator, a render farm node, an asset pipeline step, is in scope. That is a large and often invisible attack surface, because image parsing tends to run automatically and deep inside toolchains.

The fix

Patched in OpenEXR 3.2.9, 3.3.11 and 3.4.11. Everything up to 3.4.10 is affected. Full record: CVE-2026-41142 on NVD.

Takeaway for threat modeling

Every width and height a file declares is attacker input, including in image headers. Two rules keep this class of bug out. First, do dimension arithmetic in a type wide enough that it cannot overflow, or use checked arithmetic, and cast before you multiply rather than after. Second, validate the product against a sane bound before it is ever used to size an allocation. The dangerous moment is not the overflowing write itself. It is the earlier line where a bounded-looking calculation quietly produced a number that no longer means what the rest of the code assumes.