sharp EUVD-2026-106915

Exploitation requires an application that decodes untrusted AVIF or HEIF images using sharp prior to 0.35.4, running on glibc-based Linux. The flaw is in the bundled (or globally-installed) libheif; reaching it requires that sharp's HEIF/AVIF load path (VipsForeignLoadHeif) actually process attacker-controlled image data. Achieving reliable RCE (versus a crash) is substantially more feasible when the node executable is NOT compiled as a Position Independent Executable - notably the 'official' Node.js binaries are not PIE, whereas most Linux package-manager node builds are, which mitigates. The CVSS AT:P (Attack Requirements: Present) reflects these conditional dependencies. LIMITING FACTORS: non-glibc (e.g. musl/Alpine) platforms, PIE-compiled node, and applications not exposing HEIF/AVIF decoding to untrusted input reduce or remove exposure. A documented workaround exists: sharp.block({ operation: ['VipsForeignLoadHeif'] }) disables the vulnerable decoder.

This is a credible priority for any glibc-based Linux service that decodes untrusted user-supplied images with sharp, but the real-world risk is more nuanced than the 8.9 CVSS 4.0 score suggests. The root cause is CWE-122 (heap-based buffer overflow) in the bundled libheif dependency (upstream GHSA-g89c-p67h-r497 / CVE-2026-84383 and GHSA-2jg2-4ch7-h545), reachable through sharp's AVIF/HEIF decoding path. Signals conflict on the attack vector: upstream libheif rated the flaw 'network' (AV:N), but the sharp maintainer deliberately down-rated it because sharp itself has no networking features, yielding the provided CVSS 4.0 vector of AV:L with AT:P (Attack Requirements: Present) - reflecting that successful RCE depends on specific runtime conditions rather than a clean remote code path. The advisory explicitly flags the high Subsequent System Impact (SC:H/SI:H/SA:H), i.e. full code execution on the host once the heap corruption is leveraged. Crucially, EPSS, KEV, SSVC, and POC data are all ABSENT from the provided input: there is no public exploit identified at time of analysis and no confirmed active exploitation. The advisory wording is also cautious - 'possible remote code execution' under 'certain conditions' - meaning weaponized exploitation is not demonstrated, only plausible. The practical risk is therefore gated by deployment specifics (see exploitation_conditions): notably, exploitation to RCE is far more feasible when the node binary is NOT compiled as a Position Independent Executable, which is the case for the 'official' Node.js binaries. Verify your node build and image-processing exposure before deprioritizing.

An application that accepts user-uploaded images and processes them with sharp < 0.35.4 (e.g. thumbnail generation) is sent a crafted AVIF or HEIF file; when sharp hands the image to the bundled libheif for decoding, a heap buffer overflow is triggered, potentially leading to arbitrary code execution on a glibc-based Linux host - especially if node was not built as a PIE. No public exploit code was identified in the provided data, and the advisory describes RCE as 'possible' under 'certain conditions' rather than demonstrated.