CVE-2026-40385

What it actually does

CVE-2026-40385 is an unsigned 32-bit integer overflow in libexif's Nikon MakerNote parsing logic. When a 32-bit build of libexif processes a specially crafted EXIF/Nikon MakerNote structure, arithmetic used to calculate offsets or lengths can wrap, potentially causing out-of-bounds memory access. The documented impact is limited to local attackers and 32-bit systems, with possible process crashes and limited information disclosure. Integrity impact is not indicated, and there is no evidence of remote code execution from the provided data.

Why it matters to the business

Applications that use 32-bit builds of libexif to parse images may be vulnerable to denial of service or limited data exposure when handling malicious image files. The practical business risk is disruption of image-processing workflows, thumbnail generation, media indexing, document ingestion, or desktop applications that automatically parse EXIF metadata. Risk is lower overall because exploitation requires a local attack scenario, 32-bit systems, high attack complexity, and there is no known public exploitation, KEV listing, or ransomware association; however, organizations with legacy 32-bit platforms or automated image-processing pipelines should still prioritize validation and patching during normal maintenance cycles.

How an attack unfolds

An attacker prepares an image file containing malformed EXIF metadata, specifically a Nikon MakerNote structure designed to trigger a 32-bit unsigned integer wraparound in vulnerable libexif versions through 0.6.25. The attacker must then get the vulnerable software to parse that file on a 32-bit system. This could occur through a local user opening the file, an application indexing a local image directory, or a workflow that processes user-supplied images using a vulnerable 32-bit libexif build. When the crafted metadata is parsed, the overflow can lead to invalid memory access, causing the consuming application to crash or potentially disclose limited process memory. No mature exploit, active exploitation, named threat actor activity, or ransomware use is indicated in the provided intelligence.

How to fix it

Inventory systems and applications using libexif, with special attention to 32-bit builds and software that parses untrusted image files. Upgrade libexif to a version newer than 0.6.25 once a fixed upstream release or vendor package is available. Where vendor-fixed package versions exist, apply the vendor security update rather than building ad hoc replacements. If immediate patching is not possible, reduce exposure by disabling automatic EXIF parsing for untrusted images, rejecting or stripping EXIF metadata at upload or ingestion boundaries, sandboxing image-processing components, running parsers with least privilege, and preferring 64-bit builds where operationally feasible because the described issue only affects 32-bit systems.

How to confirm the fix worked

Confirm whether affected software links against libexif and determine the library version and architecture. On Linux-like systems, check package manager metadata, application dependencies, and binary architecture using tools such as package inventory commands, ldd, file, and software composition analysis. Exposure is most relevant where libexif is version 0.6.25 or earlier and compiled/running as 32-bit. Validate remediation by confirming libexif has been upgraded to a vendor-fixed release or a version later than 0.6.25, confirming the consuming application loads the updated library, and testing representative image-processing workflows with malformed EXIF test files in a controlled environment to ensure they fail safely without crashes.

Typical attack path

1. Identify a target application or workflow using libexif through 0.6.25 on a 32-bit system.
2. Create or obtain an image file with crafted EXIF data containing a malformed Nikon MakerNote structure.
3. Place the file where the vulnerable application will process it, or convince a local user or process to open/index it.
4. Trigger EXIF metadata parsing through thumbnail generation, media indexing, image viewing, or automated file processing.
5. Cause the application to crash or potentially expose limited memory contents due to integer overflow and out-of-bounds access behavior.

How to detect it

Look for evidence that vulnerable 32-bit image-processing applications unexpectedly crashed after handling image files with Nikon MakerNote EXIF metadata. Useful sources include application logs, system crash logs, core dump records, endpoint telemetry, media indexer or thumbnailer logs, file-ingestion service logs, and EDR process crash events. Search for crashes or segmentation faults in processes known to use libexif, especially shortly after new or unusual image files were created, opened, uploaded, indexed, or processed. If available, inspect suspect files for EXIF MakerNote/Nikon metadata and preserve them for forensic analysis. Since no public exploit maturity or specific campaign indicators are provided, detection should focus on behavioral evidence: abnormal crashes, repeated parser failures, core dumps, and suspicious local image files processed by 32-bit libexif consumers.

• libexif.so.12
• libexif.so
• Nikon MakerNote
• MakerNote
• Nikon
• Segmentation fault
• segfault
• core dumped
• SIGSEGV
• thumbnailer
• tracker-extract
• exif
• exiftool

What your security team should do

• Prioritize identifying 32-bit systems and 32-bit applications that use libexif through 0.6.25, especially those processing untrusted images.
• Patch or upgrade libexif through standard vendor channels when fixed packages are available; otherwise track upstream and distribution advisories for fixed versions.
• Temporarily disable, sandbox, or isolate EXIF parsing in workflows that ingest images from untrusted users or external sources.
• Add crash monitoring for image viewers, thumbnailers, media indexers, upload processors, and document/image ingestion services that use libexif.
• Harden image-processing pipelines by stripping metadata before deeper processing and applying least-privilege execution controls.
• Treat exploitation likelihood as currently low because EPSS is very low, stable over 30 days, exploit maturity is listed as none, and the issue is not in CISA KEV; reassess if exploit code or vendor advisories emerge.