Alex Laboirie
← All findings

ImageMagickCVE-2026-24481

When an image contains bytes that weren’t in the file

Converting a Photoshop file could put leftover memory into the output image. This was the bug behind my first bounty.

By Alex Laboirie5 minute readFixed · High 7.5€1,000 bounty

01 · The result

Memory that became image data

ImageMagick reads, resizes and converts images. In the local tests, repeated conversions of the same Photoshop file produced different output files. Their hashes — fingerprints of the file contents — confirmed that the bytes were changing.

Changing output alone was not enough to explain the bug. The important part was where the extra data came from: memory that the image reader had not filled with pixels from the file. The conversion could finish normally and carry those bytes into the saved picture.

I submitted the report on December 24, 2025. The issue was later published as CVE-2026-24481.

02 · The mechanism

Reserved is not the same as written

A Photoshop document, or PSD, can contain several image layers. To make the file smaller, a layer's pixels can be compressed. Reading the file means expanding that compressed data back into pixels.

ImageMagick sets aside a temporary area of memory for those pixels, called a buffer. That memory may have been used before. Reserving it does not necessarily erase its old contents: the program must write the new image data before reading it back.

In the affected path, expanding the compressed layer produced less data than expected. Only part of the buffer received new image data. But the next step read the whole expected area, treating the untouched remainder as pixels too.

Where the extra pixels came from

  1. 01 Reserve space for the image layer

    Expected amount of image data

  2. 02 Fill only part of that space

    Data from this image
    Not filled with image data

  3. 03 Read all of it as pixels

    Pixels from the file
    Memory contents become pixels

Illustration, not a captured image or a measured size ratio. The untouched area could hold old data or a repeating pattern inserted by a memory-management tool.

This is called an uninitialized-memory disclosure: the program exposes memory it has not filled with the data it is supposed to contain. Here, the output image was the way that memory left the program.

Finishing the compressed input did not mean that every expected pixel had been produced. The reader needed to check that distinction before using the buffer.

03 · The observations

The image was the way out

The local tests showed a path from the program's memory into its output. If a service used the vulnerable reader and returned the converted image to a user, memory contents could leave with it. The tests did not recover another user's secrets or demonstrate control of a server.

The varying output was a symptom, not a requirement. Leftover bytes can happen to stay the same between runs. A stable image would not make the underlying read safe.

Tested versions and evidence

The original report records local conversions on ImageMagick 7.1.2-12 and 6.9.11-60. The affected code path handled ZIP-compressed PSD layers.

This account uses the tests documented in the original report and the public advisory. No new tests were run for the article.

04 · The outcome

My first bounty

The report was accepted on January 26, with a €1,000 reward. This was my first paid report.

  1. Report submitted to ImageMagick through YesWeHack.

  2. The report was accepted and awarded €1,000. It was my first bug-bounty reward.

  3. The advisory was published as CVE-2026-24481.

The public advisory rates the issue High, with a CVSS score of 7.5. It lists versions before 7.1.2-15 and 6.9.13-40 as affected, and those two releases as patched. Its stated impact is potential exposure of sensitive server-memory contents.

Thank you to the ImageMagick maintainers for the fix and public advisory.

Public references