---

Summary:
Recently, a new vulnerability, CVE-2025-61143, was found in the popular TIFF image library, libtiff (versions up to 4.7.1). This bug is a NULL pointer dereference in the libtiff/tif_open.c component. A NULL pointer dereference is a kind of crash bug. Though it may not always lead to remote code execution, it can still be abused by attackers to crash systems and possibly exploit other weaknesses, especially when libtiff is used in server-side applications or automated image processing.

Let’s break down what happened, how it works (with code), and what you should do.

What’s libtiff?

libtiff is a widely-used, open-source C library for reading and writing TIFF image files. Many photo editors, scanners, and even mobile apps depend on this library for handling TIFF images.

The Vulnerability Details

CVE-2025-61143 describes a NULL pointer dereference bug in libtiff/tif_open.c. In simple terms, this means that the library sometimes tries to access memory through a pointer that has not been set to a valid location (i.e., it’s NULL). This usually causes the process to crash.

Where Exactly?

The bug happens while opening certain malformed TIFF files. The function in tif_open.c responsible for initializing the TIFF structure doesn’t do enough checks before using a pointer that could be NULL after a failed allocation or operation.

How Does It Work? (with Code)

Suppose an attacker crafts a malformed TIFF file. When libtiff tries to open it, it can trigger the bug. Let’s look at a simplified code path that shows the problem.

// In libtiff/tif_open.c

TIFF* TIFFOpen(const char* filename, const char* mode) {
    TIFF* tif = _TIFFmalloc(sizeof(TIFF));
    if (!tif) {
        // Allocation failed
        return NULL;
    }
    // ... more code ...
    tif->tif_fd = open(filename, O_RDONLY);
    if (tif->tif_fd < ) {
        _TIFFfree(tif);
        return NULL;
    }
    // ... more code ...
    // Maybe forgot to check tif != NULL somewhere else
    some_function(tif);
}

But in reality, deeper in the code (especially when working with callbacks or plugin handlers), a pointer usage like:

tif->tif_clientdir->field

may be called without validating tif->tif_clientdir is non-NULL, resulting in a crash if the allocation failed or the structure wasn’t initialized right.

In an Exploit scenario, an attacker sends you a TIFF file that, when opened, causes your application (server, script — whatever is using libtiff) to crash.

Example Exploit (Crash a Target Application)

Let’s suppose you have a simple Python tool that uses libtiff via bindings such as Pillow (which uses libtiff under the hood). An attacker can drop in a malicious TIFF file like this (say, evil.tiff):

from PIL import Image

try:
    img = Image.open('evil.tiff')
    img.load()
except Exception as e:
    print("Cracked! The program crashed or threw an error: ", e)

If you feed in an evil TIFF designed to trigger the NULL dereference, your application will abort — this is a Denial of Service (DoS).

Original References

- CVE-2025-61143 on MITRE *(placeholder, make sure to search since it may not be live yet)*
- libtiff official page
- Upstream libtiff GitLab issues
- Pillow library (Python TIFF handling)

Update libtiff right away to the latest patched version (post-4.7.1).

2. If a patch is not yet available, consider disabling uploads or converting TIFFs to safe formats before processing.

In Closing

NULL pointer dereferences might seem “harmless,” since they often only crash an application. However, when used against vulnerable servers and processing chains, they are a useful weapon for attackers. This CVE-2025-61143 bug in libtiff is currently confirmed as a denial-of-service, but keeping your dependencies up to date keeps your systems safer from even deeper exploit chains that could come in the future.

Timeline

Published on: 02/23/2026 00:00:00 UTC
Last modified on: 02/25/2026 15:20:49 UTC