Which versions of libvips are affected by CVE-2026-35591?

libvips, a widely-used image processing library, has a critical heap buffer overflow vulnerability affecting versions 8.18.1 and earlier.

How to fix or mitigate CVE-2026-35591?

Within 24 hours, identify all applications and systems in your infrastructure using libvips 8.18.1 or earlier, specifically noting which ones process TIFF images. Within 7 days, obtain libvips 8.18.2, test it thoroughly in a staging environment, and prepare rollout procedures. Within 30 days, upgrade all production systems to libvips 8.18.2, prioritizing customer-facing applications and those handling external image uploads.

libvips CVE-2026-35591

Q: What is the CVSS score of CVE-2026-35591?

CVE-2026-35591 has a CVSS 4.0 base score of 7.0 (High). CVSS vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.1%.

EUVD-2026-46004 HIGH

Heap-based Buffer Overflow (CWE-122)

2026-07-20 GitHub_M

Buffer Overflow Heap Overflow Libvips

7.0

CVSS 4.0 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

7.0 HIGH

CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

9.1 CRITICAL

Malicious images commonly reach libvips-backed upload/thumbnail pipelines unauthenticated, so AV:N/PR:N; heap overflow yields high integrity/availability impact but no direct data disclosure, so C:N.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

Red Hat

7.3 HIGH

qualitative

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 20, 2026 - 17:55 vuln.today

Analysis Generated

Jul 20, 2026 - 17:55 vuln.today

CVE Published

Jul 20, 2026 - 16:24 cve.org

HIGH 7.0

DescriptionCVE.org

libvips is a fast image processing library with low memory needs. The tiffload operation in libvips versions before and including 8.18.1 could incorrectly determine the number of channels in a JPEG or JPEG2000-encoded tile within a TIFF image, leading to a possible buffer overflow. This has been patched in version 8.18.2.

AnalysisAI

Heap buffer overflow in libvips' tiffload operation (versions ≤ 8.18.1) lets an attacker who supplies a crafted TIFF image trigger memory corruption during decode. The flaw stems from libvips incorrectly determining the channel/component count of a JPEG- or JPEG2000-encoded tile embedded in a TIFF, so the pixel buffer is sized from the TIFF photometric metadata while more components are written from the codec. No public exploit has been identified at time of analysis; the issue is fixed in 8.18.2.

Technical ContextAI

libvips is a widely embedded C image-processing library (notably the engine behind the Node.js 'sharp' package and many server-side thumbnailers). The bug lives in the TIFF reader (tiff2vips.c) where TIFF tiles may themselves be compressed with JPEG or JPEG2000. libvips derives bytes-per-pixel from the TIFF's photometric_interpretation tag, but the actual number of color components is decided by the inner JPEG/JP2K codec. When these disagree, the decompressed tile writes more channels than the destination buffer was allocated for, producing a classic CWE-122 heap-based buffer overflow. The fix adds explicit validation: tiff2vips.c now rejects tiles where cinfo->output_components != bytes_per_pixel, and jp2kload.c hardens its component/geometry/precision checks (including numcomps vs out->Bands) via the refactored vips_foreign_load_jp2k_check_supported().

RemediationAI

Vendor-released patch: 8.18.2 - upgrade libvips to 8.18.2 or later, which adds the component-count validation for JPEG and JP2K tiles (fix PR https://github.com/libvips/libvips/pull/4973, commit df044e409a0db77c980fa1a9f86a13fbfb2dc8fe). If you consume libvips indirectly (e.g. via 'sharp' or OS packages), rebuild or update those packages against a patched libvips. Where immediate upgrade is not possible, the practical compensating control is to restrict which images reach tiffload: reject or do not route TIFF inputs to libvips (or disable the TIFF loader in your pipeline), since the bug is specific to JPEG/JP2K-in-TIFF decoding - the trade-off is loss of TIFF support for legitimate users. Additionally, sandbox/resource-limit the image-processing workers (separate process, seccomp, memory limits) so a corrupted heap is contained to a crash rather than the host; this adds operational overhead but limits blast radius. See GHSA-523x-vhfw-6r76 for details.