CVE-2026-70653 in libvips
Summary
by MITRE • 08/21/2026
libvips is a fast image processing library with low memory needs. Prior to version 8.18.3, the old-style Radiance RLE decoder in libvips/foreign/radiance.c can process a repeat marker at the beginning of a scanline in scanline_read_old and read q[-1] before any prior pixel exists. A crafted Radiance image loaded through VipsForeignLoadRad can therefore disclose four bytes of adjacent heap data, most likely other image data. This issue is fixed in version 8.18.3.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in libvips versions prior to 8.18.3 represents a critical memory safety flaw within the legacy Radiance RLE decoder implementation located in the radiance.c source file. Libvips is widely utilized for high-performance image processing due to its efficiency and low memory footprint, making it a common dependency in various multimedia pipelines and web services that handle user-uploaded images. The specific defect resides in the scanline_read_old function, which handles older-style Radiance RLE encoded data. During the decoding process, when encountering certain repeat markers at the beginning of a scanline, the algorithm attempts to access memory using an index offset of negative one relative to the current position. This operation results in reading from q[-1], accessing memory immediately preceding the allocated buffer for the current pixel row. Since no prior pixel data has been established or written into that location within the context of this specific decoding step, the code effectively reads uninitialized or adjacent heap memory rather than valid image data.
This out-of-bounds read constitutes a classic off-by-one error in pointer arithmetic, leading to an information disclosure vulnerability. When a maliciously crafted Radiance image is processed through VipsForeignLoadRad, the application does not crash but instead leaks four bytes of adjacent heap content back into the processing pipeline or potentially to the output stream depending on how the decoded data is subsequently used. The leaked data most likely consists of other image pixels stored in contiguous memory blocks, which could reveal sensitive visual information from previously processed images if multiple images are handled within the same process lifetime due to libvips' typical reuse of memory pools for performance optimization. This behavior aligns with CWE-125, Out-of-bounds Read, as it involves reading beyond the intended boundary of a buffer without proper validation checks before accessing the memory location.
The operational impact of this vulnerability is primarily centered on confidentiality rather than availability or integrity in its immediate form. An attacker who can induce an application using libvips to process untrusted Radiance images could potentially extract sensitive data from the server's memory space. In environments where multiple users' images are processed concurrently, such as cloud-based image editing services or content management systems, this leak could expose private user photos, internal document thumbnails, or other proprietary visual assets. While four bytes is a small amount of data per instance, repeated exploitation across many requests can allow an attacker to reconstruct significant portions of adjacent memory regions through statistical analysis or by carefully crafting payloads that align with specific heap layouts. This falls under the ATT&CK technique T1074, Data Staged, specifically Local Data Staging if the leaked data is used for further local exploits, though it more directly maps to information gathering techniques where an adversary seeks to exfiltrate sensitive information from a compromised system.
Mitigation strategies require immediate updates to the underlying image processing library. Organizations relying on libvips must upgrade to version 8.18.3 or later, where this boundary check has been corrected to prevent access to memory preceding the current scanline buffer. For applications that cannot immediately update their dependencies, input validation at the ingestion layer is recommended. This includes rejecting Radiance files with malformed RLE headers or limiting the size and complexity of images processed by libvips instances exposed to untrusted inputs. Additionally, employing sandboxing techniques such as running image processing tasks in isolated containers or using memory protection features like Address Sanitizer during development can help detect similar issues early in the software lifecycle before they reach production environments. Regular auditing of third-party dependencies for known vulnerabilities is essential to maintain a secure posture against these types of low-level memory corruption flaws.