CVE-2026-111272 in LibRaw
Summary
by MITRE • 10/16/2026
LibRaw through 0.22.2 contains a heap-based out-of-bounds read in LibRaw::parseNikonMakernote() that allows attackers to read past a short ShotInfo buffer. Attackers can supply a crafted Nikon NEF/TIFF with a 5-byte ShotInfo tag declaring version 243 to crash applications decoding the image.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in LibRaw versions up to and including 0.22.2 represents a critical memory safety issue classified as an out-of-bounds read, specifically mapped to CWE-125 under Common Weakness Enumeration standards. This flaw resides within the parseNikonMakernote function, which is responsible for parsing metadata embedded in Nikon camera raw image files. The technical root cause involves improper boundary checking when processing the ShotInfo tag structure. Specifically, the parser fails to validate that the declared size of the ShotInfo buffer matches or exceeds the actual data being read from the file. This lack of rigorous input validation allows an attacker to craft a malicious NEF or TIFF file where the metadata header declares a version number of 243 for the ShotInfo tag while providing significantly less actual data than expected by the parser logic.
When an application utilizing LibRaw processes this crafted image, the library attempts to read from memory locations that lie beyond the allocated buffer boundaries defined by the short ShotInfo structure. Because the declared version triggers a code path expecting more data than is present in the file payload, the pointer arithmetic results in reading arbitrary adjacent memory contents. This constitutes an out-of-bounds read vulnerability which can lead to information disclosure if the application subsequently processes or displays these leaked bytes. However, as noted in the initial report, the immediate and most observable impact is often a denial of service condition. The invalid memory access typically triggers segmentation faults or similar critical errors within the host application, causing it to crash unexpectedly when decoding the malicious image file.
From an operational perspective, this vulnerability poses significant risks to any software ecosystem that relies on LibRaw for image processing workflows. This includes digital asset management systems, photo editing applications, web galleries that auto-generate thumbnails from uploaded raw images, and automated content ingestion pipelines. An attacker could exploit this flaw by distributing maliciously crafted NEF or TIFF files through email attachments, social media platforms, or file-sharing services. When a victim opens the image in a vulnerable application, the resulting crash disrupts service availability and can degrade user trust. In more complex scenarios involving server-side processing of uploaded images, repeated exploitation attempts could lead to resource exhaustion if the crashing process is not properly restarted by an external supervisor, thereby facilitating a denial-of-service attack against the hosting infrastructure.
Mitigation strategies must focus on both immediate patching and long-term defensive coding practices. The primary remediation step is to upgrade LibRaw to version 0.23 or later, where this specific boundary check has been corrected to ensure that buffer sizes are validated before any read operations occur. For organizations unable to immediately update their dependencies, implementing input validation at the application layer can provide a temporary defense-in-depth measure. This involves verifying metadata integrity and file structure consistency before passing data to the parsing library. Additionally, deploying runtime protection mechanisms such as Address Sanitizer during testing phases or utilizing memory-safe wrappers in production environments can help detect similar vulnerabilities early in the development lifecycle. Security teams should also monitor for new CVEs related to image processing libraries and ensure that all third-party components are kept up-to-date with security patches aligned with industry standards like CWE-125 guidelines for buffer boundary validation.