CVE-2026-2913: 
Wolfi vulnerability analysis and mitigation

CVE-2026-2913 is a heap-based buffer overflow vulnerability in libvips up to and including version 8.19.0, caused by an integer truncation flaw in the vips_source_read_to_memory() function within libvips/iofuncs/source.c. The vulnerability was reported on February 10, 2026, and publicly disclosed on February 22, 2026. It affects all libvips versions through 8.19.0 when processing custom seekable sources larger than 4 GiB. The CVSS v3.1 base score is 7.0 (High), though the practical severity is considered low given the narrow exploitation conditions (Red Hat Bugzilla, Feedly).

The root cause is an incorrect calculation of buffer size (CWE-131) and improper restriction of memory buffer operations (CWE-119, CWE-122). The function vips_source_read_to_memory() allocates a GByteArray using source->length, which is a 64-bit gint64, but passes it to g_byte_array_set_size(), which accepts only a 32-bit guint. When source->length exceeds G_MAXUINT (i.e., values greater than 4 GiB), the allocation silently truncates to a smaller buffer while the subsequent read loop continues writing up to the full 64-bit length, causing a heap-buffer-overflow write past the allocated region. Exploitation requires a local attacker with low privileges to supply a custom seekable source with a reported length exceeding 4 GiB; the crash occurs in user code rather than within libvips itself. A public proof-of-concept using ASAN/UBSAN was disclosed in the original GitHub issue (libvips Issue #4857, libvips Commit).

Successful exploitation results in a heap-buffer-overflow write, which can cause a denial of service (application crash) in the calling user code. The libvips maintainers note that confidentiality and integrity impacts are negligible in practice, as the crash occurs in user code rather than within libvips itself, and the condition is only triggerable with custom seekable sources exceeding 4 GiB. There is no evidence of lateral movement potential or data exfiltration risk associated with this vulnerability (Red Hat Bugzilla, Feedly).

A proof-of-concept exploit was publicly disclosed in the libvips GitHub issue tracker at the time of reporting, demonstrating the heap-buffer-overflow using AddressSanitizer on Ubuntu 22.04 with libvips 8.19.0. The EPSS score is 0.013% (very low), and there is no evidence of in-the-wild exploitation or inclusion in the CISA KEV catalog. No threat actor attribution has been identified. The attack requires local access, low privileges, and high complexity, significantly limiting real-world exploitability (libvips Issue #4857, Feedly).

1. Setup: Obtain local access to a system running libvips ≤ 8.19.0 with low-privilege credentials.
2. Craft a malicious custom source: Implement a VipsSourceCustom with seek and read callbacks that report a source length exceeding G_MAXUINT (e.g., (gint64) 1 << 32 + 1024, approximately 4 GiB + 1024 bytes).
3. Trigger the overflow: Call vips_source_map() on the custom source. Internally, vips_source_read_to_memory() calls g_byte_array_set_size() with the truncated 32-bit value, allocating a smaller buffer than the reported length.
4. Heap-buffer-overflow: The read loop writes data up to the full 64-bit length into the undersized buffer, causing a heap-buffer-overflow write past the allocated region and resulting in a crash (denial of service) in the calling application (libvips Issue #4857).

• Process: Application crashes or abnormal termination of processes using libvips when processing large custom seekable sources; ASAN/UBSAN reports of heap-buffer-overflow in vips_source_read_to_memory() or vips_source_map().
• Logs: Application error logs showing AddressSanitizer: heap-buffer-overflow at libvips/iofuncs/source.c line ~971; error messages containing length overflow after patching is applied.
• File System: Presence of PoC source files (e.g., poc_s001.c) or compiled binaries that implement custom VipsSourceCustom with oversized length values on the local system (libvips Issue #4857).

Apply the upstream patch commit a56feecbe9ed66521d9647ec9fbcd2546eccd7ee, which adds explicit overflow checks in vips_source_read_to_memory() and vips_source_sniff_at_most() to reject sources with lengths exceeding UINT_MAX before allocation. Organizations not using custom seekable sources larger than 4 GiB face negligible practical risk. Upgrade libvips to a version incorporating this patch (post-8.19.0); Red Hat has tracked this via Bugzilla and Chainguard/Wolfi have also issued advisories. No configuration-based workaround is available beyond avoiding the use of custom seekable sources exceeding 4 GiB (libvips Commit, Red Hat Bugzilla).

Red Hat tracked the issue at low severity (Priority: Low, Severity: Low) via their Bugzilla system, reflecting the limited practical impact. The libvips maintainers acknowledged the bug and confirmed the fix, noting in the patch confirmation that "the impact of this is negligible, since this only affects custom seekable sources larger than 4 GiB (and the crash occurs in user code rather than libvips itself)." No significant broader media coverage or notable researcher commentary beyond the original disclosure has been identified (Red Hat Bugzilla, libvips Issue #4857).