CVE-2026-40386: 
NixOS vulnerability analysis and mitigation

CVE-2026-40386 is an integer underflow vulnerability in libexif through version 0.6.25 affecting the MakerNote decoding logic for Fuji and Olympus camera metadata. The flaw was disclosed on April 12, 2026, and a patch was committed to the libexif GitHub repository on April 14, 2026. It carries a CVSS v3.1 base score of 7.1 (High) per NVD scoring, with impacts to both confidentiality and availability (GitHub Advisory, libexif Commit).

The root cause is an integer underflow (CWE-191) in the size-checking logic within exif-mnote-data-fuji.c and exif-mnote-data-olympus.c. Specifically, the bounds check if (i > n->count - 1) is vulnerable when n->count is zero: subtracting 1 from an unsigned integer wraps around to a very large value, causing the check to pass incorrectly and allowing out-of-bounds memory access. The fix replaces this with if (i >= n->count), which correctly handles the zero-count case. Exploitation requires supplying a crafted image file with malicious Fuji or Olympus MakerNote EXIF data to a program using libexif (libexif Commit, GitHub Advisory).

Successful exploitation can result in denial of service (application crash) or information disclosure (memory leakage) from any application that uses libexif to parse image metadata. The vulnerability affects confidentiality and availability but not integrity. Applications processing user-supplied images — such as photo management tools, web services, or media libraries — are at risk if they depend on a vulnerable version of libexif (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of reporting. The EPSS score is approximately 0.013%, indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires local access and the ability to supply a crafted image file to a vulnerable application (GitHub Advisory).

1. Craft a malicious image file: Create a JPEG or TIFF file with a specially crafted Fuji or Olympus MakerNote EXIF segment where the MakerNote entry count is set to zero.
2. Trigger the vulnerable code path: Supply the crafted image to a target application that uses libexif ≤ 0.6.25 for EXIF parsing (e.g., a photo viewer, image upload service, or media indexer).
3. Trigger the integer underflow: When exif_mnote_data_fuji_get_value or exif_mnote_data_olympus_get_value is called with index i = 0 and n->count = 0, the check i > n->count - 1 evaluates as 0 > UINT_MAX, which is false, bypassing the bounds check.
4. Achieve crash or memory leak: The out-of-bounds memory access either causes the application to crash (denial of service) or reads adjacent memory contents, potentially leaking sensitive data from the process (libexif Commit, GitHub Advisory).

• File System: Presence of crafted JPEG/TIFF files with anomalous or zero-count Fuji/Olympus MakerNote EXIF segments in directories processed by libexif-dependent applications.
• Logs: Application crash logs or core dumps originating from processes invoking exif_mnote_data_fuji_get_value or exif_mnote_data_olympus_get_value; segmentation fault signals from image processing services.
• Process: Unexpected termination (SIGSEGV or SIGABRT) of image processing applications after handling user-supplied image files; abnormal memory read patterns in applications using libexif.

Upgrade libexif to a version beyond 0.6.25 that includes the fix from commit dc6eac6e9655d14d0779d99e82d0f5f442d2f34b. Major Linux distributions including Red Hat (RHSA-2026:20929, RHSA-2026:22553, RHSA-2026:22529), Debian (DLA-4558-1), Fedora (Fedora 42, 43, 44), AlmaLinux, Rocky Linux, openSUSE, Slackware, and Mageia have all issued updated packages. As a workaround where patching is not immediately possible, restrict processing of image files to trusted sources and avoid exposing libexif-dependent services to untrusted user-supplied images (GitHub Advisory, Red Hat Advisory, Debian LTS).

The vulnerability received broad attention from Linux distribution maintainers, with rapid patch releases across Red Hat, Debian, Fedora, AlmaLinux, Rocky Linux, openSUSE, Slackware, and Mageia within weeks of disclosure. Microsoft also acknowledged the vulnerability's impact on Azure Linux (AZL3) and CBL-Mariner 2 packages. The NixOS community tracked the issue via a GitHub issue, and security news aggregators such as LinuxSecurity.com and LinuxCompatible.org covered the distribution-level updates (Red Hat Advisory, Debian LTS, Microsoft MSRC).