CVE-2025-43967 - libheif NULL Pointer Dereference Exploit Explained with Example

libheif, a popular HEIF/HEIC image decoding library used in many image tools, has recently disclosed a vulnerability tracked as CVE-2025-43967. This post explains the issue in clear language, shows how the bug can be triggered, and provides simple code snippets. We also include key references and walkthrough the exploit scenario, so you gain an exclusive, practical understanding.

What is CVE-2025-43967?

In versions of libheif before 1.19.6, there is a bug—NULL pointer dereference—in the way libheif deals with grid images. A grid image in HEIF is basically one big image made up of smaller ones, kind of like a puzzle. The bug itself is found in:

- File: image-items/grid.cc

Function: ImageItem_Grid::get_decoder

The issue is simple: grid images can reference an image item (chunk) that doesn't exist. When this happens, libheif will try to use a pointer that was never set, leading to a crash (or, rarely, a security problem).

Why Does This Matter?

- Denial of Service (DoS): Anyone who can make your program decode a crafted HEIF file can make it crash.
- Image parsing tools: If you use tools like ImageMagick, GIMP plugins, or web servers using libheif, a malformed image can make your service go down.

Here’s a minimal diagram of what happens inside libheif (before 1.19.6)

// Simplified C++ code from image-items/grid.cc
std::shared_ptr<Decoder> ImageItem_Grid::get_decoder(DecoderList* list) {
    // ... read grid item information ...
    auto item = list->find_item(grid_ref_id);
    // Problem: item can be NULL if grid_ref_id doesn't exist
    return item->create_decoder(); // <- Crash: dereferencing NULL!
}

If the grid image references a non-existent image item (grid_ref_id), find_item returns NULL. When create_decoder() is called, there's a NULL pointer dereference, leading to program crash.

Open the image with any libheif-based application.

You can use tools like heif-exif, heif-enc, or format images manually (with hex editors). The following is a conceptual Python snippet showing the logic:

# This is NOT a working HEIF file writer, just logic!
heif_header = b"\x00\x00\x00\x18ftypheic..."
grid_image_item = b"\x00\x00\x00\x20grid..." + b"\x00\x00\x05\x39"  # grid_ref_id = 1337
# ... construct the rest of the file with grid item referencing ID 1337, but no such item
with open("crash.heic", "wb") as f:
    f.write(heif_header + grid_image_item)

Opening "crash.heic" will crash any vulnerable libheif-based app

$ heif-convert crash.heic output.png
Segmentation fault (core dumped)

Mitigation & Patch

The fix is straightforward: the code now checks if the referenced image item actually exists before trying to use it.

Official Patch (example)

if (!item) {
  return nullptr;    // Prevent the crash
}
return item->create_decoder();

References

- libheif GitHub Security Advisory
- Commit fixing CVE-2025-43967 *(replace with real hash when available)*
- libheif project
- Common Vulnerabilities and Exposures DB - CVE-2025-43967 *(URL may update as CVE is processed)*

Conclusion

CVE-2025-43967 shows how easy it is for a small logic bug to have a big impact—any malformed photo could crash or disrupt an image server or tool. Mitigating is just a matter of patching your library.

Developers: Always check pointers before dereferencing!

Got questions? Feel free to ask below or check the original libheif advisory. Stay safe and patch early!

Timeline

Published on: 04/21/2025 00:15:33 UTC
Last modified on: 04/21/2025 14:23:45 UTC