CVE-2026-35590: 
Wolfi vulnerability analysis and mitigation

CVE-2026-35590 is a null pointer dereference / heap-based buffer overflow vulnerability in libvips, a fast image processing library, affecting all versions up to and including 8.18.1. The flaw resides in the EXIF decoder, which failed to validate the range of EXIF tag group (ifdN) values before passing them to libexif, enabling a crafted image to crash the application. It was responsibly disclosed by Trail of Bits and patched in libvips 8.18.2, with the fix merged on March 26, 2026, and the advisory published on July 17–20, 2026. The vulnerability carries a CVSS v4.0 base score of 6.8 (Medium) (GitHub Advisory).

The root cause is classified as CWE-122 (Heap-based Buffer Overflow), with an associated CWE-476 (NULL Pointer Dereference) estimate. In libvips/foreign/exif.c, the function vips_exif_image_field() parsed the ifdN integer from EXIF field names using atoi() but performed no bounds check against the valid range [0, EXIF_IFD_COUNT) before using the value as an index into libexif data structures. An attacker supplying a specially crafted image with an out-of-range EXIF tag group value could trigger a null pointer dereference or heap read beyond allocated memory, causing a crash. The fix (commit 91ebd4d) adds a simple range guard that returns NULL and emits a warning when ifd < 0 || ifd >= EXIF_IFD_COUNT (GitHub PR #4972, Fix Commit).

Successful exploitation causes a crash of the libvips process (availability impact: High), resulting in denial of service for any application that relies on libvips for image processing — such as web servers, media pipelines, or thumbnail generators. There is no confidentiality or integrity impact; the vulnerability cannot be used to exfiltrate data or modify system state. Because libvips is often embedded in server-side image processing workflows, a crash could disrupt service availability for end users or downstream systems (GitHub Advisory).

1. Craft a malicious image: Create an image file (e.g., JPEG or TIFF) with embedded EXIF metadata containing an out-of-range ifdN tag group value — specifically, a value less than 0 or greater than or equal to EXIF_IFD_COUNT — in the EXIF field name (e.g., exif-ifd<N>-...).
2. Deliver the image: Supply the crafted image to a system or application that uses libvips ≤ 8.18.1 for image processing. This may require local access or the ability to upload files to a service that processes images with libvips.
3. Trigger EXIF decoding: Cause libvips to decode the EXIF metadata of the crafted image, which invokes vips_exif_image_field() in libvips/foreign/exif.c.
4. Trigger crash: The unvalidated ifdN value is passed as an index to libexif without bounds checking, resulting in a null pointer dereference or out-of-bounds heap read, crashing the libvips process and any application depending on it (GitHub PR #4972, Fix Commit).

• Logs: Application crash logs or core dumps referencing vips_exif_image_field or libvips/foreign/exif.c; g_warning messages containing "bad exif ifd" (present only in patched versions as a diagnostic).
• Process: Unexpected termination (segfault/SIGSEGV) of processes using libvips when processing image files with unusual EXIF metadata.
• File System: Presence of crafted image files with anomalous EXIF structures (e.g., ifdN values outside the range 0–3) in directories processed by libvips-based applications.

The vendor has released libvips 8.18.2, which adds bounds checking on the ifdN EXIF tag group value before passing it to libexif. There is no known workaround; upgrading to version 8.18.2 or later is the only remediation. Operators running image processing pipelines or web services that use libvips should prioritize upgrading, particularly if untrusted image uploads are accepted (GitHub Advisory).

Trail of Bits was credited with responsible disclosure of this vulnerability, and the libvips maintainer (jcupitt) acknowledged their contribution in both the pull request and the commit message. No broader media coverage or notable community discussion has been identified beyond the GitHub advisory and associated pull request (GitHub PR #4972).