CVE-2026-32775

What it actually does

libexif through 0.6.25 contains a memory corruption flaw in MakerNote EXIF decoding. When exif_mnote_data_get_value is called with a zero-length size value, an integer underflow can cause the function to overwrite the provided buffer. Successful exploitation can corrupt process memory and may lead to process crash, arbitrary code execution, or unauthorized read/write effects within the privileges of the application using libexif.

Why it matters to the business

Applications that process images with libexif may be destabilized or compromised by a specially crafted image file. This can affect desktop image viewers, photo import tools, content-management systems, upload pipelines, media indexing services, and any downstream software that parses EXIF metadata. Although current EPSS is low, unchanged over 30 days, not listed in CISA KEV, and has no known mature exploit, the broad reuse of libexif means exposure can exist indirectly through many image-processing workflows.

How an attack unfolds

An attacker prepares an image containing malformed EXIF MakerNote metadata designed to trigger the zero-size path in libexif. The attacker then causes a vulnerable application or service to parse that image, such as by convincing a user to open it, placing it in a watched folder, uploading it to an image-processing service, or sending it through a workflow that extracts EXIF metadata. When the application invokes libexif and reaches exif_mnote_data_get_value with a zero size, the integer underflow causes an overwrite of the supplied buffer. Depending on allocator behavior, compiler hardening, process sandboxing, and surrounding memory layout, the result may be a crash, denial of service, memory disclosure, or code execution in the context of the parsing process. Exploitation is assessed as high complexity and there is no known public exploitation maturity at this time.

How to fix it

Upgrade libexif to a version containing the upstream fix as soon as one is available from the libexif project or operating-system/package maintainers. No fixed version was provided in the input, so treat libexif through 0.6.25 as affected and monitor vendor advisories for patched builds. Where immediate patching is not possible, reduce exposure by disabling EXIF MakerNote parsing where supported, stripping metadata before processing untrusted images, limiting accepted image sources, running image parsing in a sandbox or container with minimal privileges, enabling compiler/runtime hardening, and isolating thumbnailing or metadata extraction workers from sensitive systems.

How to confirm the fix worked

Inventory systems and applications for libexif usage and confirm that no deployed package or bundled library is libexif 0.6.25 or earlier once patched builds are available. Check OS package manager output, application dependency manifests, container images, statically bundled libraries, and runtime library linkage. Validate mitigations by confirming untrusted image parsing runs with restricted privileges and that EXIF/MakerNote parsing is disabled or metadata is stripped where intended. After updating, confirm the installed package version, rebuild dependent applications if they bundle or statically link libexif, and run regression tests against representative image-processing workflows.

Typical attack path

1. Identify software or services that parse EXIF metadata using libexif through 0.6.25.
2. Craft or obtain an image file with malformed MakerNote metadata that triggers the zero-size handling flaw.
3. Deliver the image to a vulnerable workflow, such as user opening, file upload, media indexing, thumbnail generation, or metadata extraction.
4. Wait for the vulnerable application to parse the EXIF MakerNote data through libexif.
5. Trigger memory corruption in the parsing process.
6. Use the resulting crash for denial of service or attempt to shape memory corruption into code execution or data exposure.

How to detect it

There are no known public exploitation indicators or named threat actors for this issue. To assess possible prior exploitation, review logs and crash telemetry from applications that parse images or EXIF metadata, especially around uploads, thumbnail generation, media indexing, and user-opened image workflows. Look for crashes, segmentation faults, heap corruption, abnormal exits, sanitizer findings, or repeated failures correlated with specific image files. Preserve suspicious image samples, core dumps, crash reports, and application logs for analysis. Useful sources include web upload logs, media-processing worker logs, desktop crash reporters, system journals, EDR process telemetry, object storage access logs, and sandbox/container exit logs. Pay particular attention to crashes involving libexif, MakerNote parsing, or exif_mnote_data_get_value after processing externally supplied images.

• exif_mnote_data_get_value
• libexif.so
• libexif.dll
• MakerNote
• ExifMnoteData
• SIGSEGV
• segmentation fault
• heap-buffer-overflow
• buffer overflow detected
• malloc(): corrupted top size
• free(): invalid pointer
• double free or corruption
• AddressSanitizer
• integer underflow

What your security team should do

• Prioritize inventory of internet-facing, file-upload, media-processing, and automated image-indexing workflows that may parse EXIF metadata with libexif.
• Track libexif and operating-system vendor advisories for the first fixed release and patch promptly when available.
• Apply compensating controls now for untrusted images: metadata stripping, sandboxed processing, privilege reduction, and workload isolation.
• Search for bundled or statically linked libexif copies in applications, appliances, containers, and third-party tools, not only OS-level packages.
• Enable crash collection and alerting for image-processing services to detect possible malformed-file attacks.
• Because the vulnerability is not currently KEV-listed and has low EPSS, prioritize based on exposure to untrusted image content rather than score alone.