8.9

CVSS Score

4.0

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

GHSA-rgj7-g3m4-5g8c

GHSA-rgj7-g3m4-5g8c: sharp: Vulnerabilities in libheif: GHSA-g89c-p67h-r497 and GHSA-2jg2-4ch7-h545

Impact

A number of vulnerabilities, two rated as "Critical" severity using CVSSv3, have been discovered and fixed in the upstream libheif dependency. These can lead to possible remote code execution (RCE) on glibc-based Linux when run under certain conditions.

The attack vector for these claims to be "network" however sharp does not provide any networking features so this vulnerability is down-rated to a "High" severity using CVSSv4 but please note its Subsequent System Impact.

Those processing untrusted input with versions of sharp prior to 0.35.4 are affected.

Patches

Using prebuilt binaries provided by sharp?

Most people rely on the prebuilt binaries provided by sharp.

Please upgrade sharp to the latest version, currently 0.35.4, which provides libheif 1.23.2.

Using a globally-installed libheif?

Please ensure you are using the latest libheif 1.23.2.

Workarounds

Add the following to your code to prevent sharp from decoding AVIF images.

sharp.block({ operation: ["VipsForeignLoadHeif"] });

Ensure you are using a node executable binary compiled as a Position Independent Executable (PIE). Most Linux package managers already do this for protection against RCE however be warned that the "official" Node.js binaries do not.

References

CVE-2026-84383
https://github.com/strukturag/libheif/security/advisories/GHSA-2jg2-4ch7-h545

(GitHub Advisory)

Miggo Vulnerability Database

→

GHSA-rgj7-g3m4-5g8c

GHSA-rgj7-g3m4-5g8c:

8.9

CVSS Score

4.0

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
sharp	npm	< 0.35.4	0.35.4

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability in sharp stems from multiple critical issues within its libheif dependency (GHSA-g89c-p67h-r497 and GHSA-2jg2-4ch7-h545). The core problem is libheif's incorrect assumption that a HeifPixelImage's logical geometry accurately describes every channel plane it holds, and that each heif_channel is backed by at most one plane. This allowed specially crafted HEIC/HEIF/AVIF files to create inconsistent image states, leading to heap-based buffer overflows and out-of-bounds reads/writes.

Specifically, the GHSA-g89c-p67h-r497 advisory details a heap buffer overflow in HeifPixelImage::scale_nearest_neighbor(). This occurred when a file with nested iden and auxl items caused transfer_channel_from_image_as() to accept duplicate Alpha planes. One Alpha plane would be 8-bit, and a subsequent one 16-bit. When scale_nearest_neighbor() then processed this image, it would allocate an 8-bit buffer (based on the first Alpha plane) but write 16-bit data (from the second Alpha plane), leading to an overflow.

The GHSA-2jg2-4ch7-h545 advisory describes a broader set of 11 vulnerabilities, including out-of-bounds reads and writes, all stemming from the same fundamental flaw in plane size validation. Functions like HeifPixelImage::crop and HeifPixelImage::extract_image_area were also affected because they would perform memory operations based on the image's declared dimensions without verifying that individual planes actually matched those dimensions.

The patches introduce robust validation checks:

HeifPixelImage::transfer_channel_from_image_as now explicitly rejects attempts to add a channel if one already exists for that type, preventing the creation of duplicate Alpha planes.
The ImageItem_iden::check_decoded_image_size override, which previously bypassed size validation for iden items, was removed. This ensures that the base class's validation logic is applied, preventing iden items from misrepresenting their dimensions.
A new helper function, HeifPixelImage::has_standard_plane_sizes(), was introduced. This function verifies that every stored plane in an image has the expected size for its channel type (e.g., full image size for Y/Alpha, subsampled size for Cb/Cr). This check is now performed by HeifPixelImage::scale_nearest_neighbor, HeifPixelImage::crop, and HeifPixelImage::extract_image_area before they perform memory-intensive operations, preventing OOB access.

When the vulnerability is triggered, a malicious HEIF/AVIF file is parsed. The parsing process would involve calls to ImageItem::decode_image (which might call ImageItem_iden::decode_compressed_image), leading to the creation of an HeifPixelImage with inconsistent plane data due to the lack of checks in transfer_channel_from_image_as and ImageItem_iden::check_decoded_image_size. Subsequently, operations like scaling, cropping, or extracting areas (HeifPixelImage::scale_nearest_neighbor, HeifPixelImage::crop, HeifPixelImage::extract_image_area) would then attempt to process this malformed image, resulting in the heap buffer overflow or out-of-bounds read/write that constitutes the exploitation.

Vulnerable functions

HeifPixelImage::scale_nearest_neighbor

libheif/image/pixelimage.cc

This function was vulnerable to a heap buffer overflow. A crafted image with duplicate Alpha planes could cause the function to write 16-bit samples into an 8-bit allocation. The patch adds a check to ensure that all image planes have standard, expected sizes before scaling, thus preventing the overflow. The ASan report in the advisory explicitly points to `pixelimage.cc:1964 in HeifPixelImage::scale_nearest_neighbor` as the location of the heap-buffer-overflow WRITE, confirming its direct involvement in the vulnerability.

HeifPixelImage::transfer_channel_from_image_as

libheif/image/pixelimage.cc

This function previously allowed attaching a new image plane to a channel that already had one. This behavior was a key part of the exploit chain, as it allowed the creation of an image with multiple Alpha planes with different properties, which then led to the overflow in `scale_nearest_neighbor`. The patch adds a check to reject duplicate channels, directly addressing one of the root causes described in the advisory ('transfer_channel_from_image_as() accepts duplicate destination channels').

ImageItem_iden::check_decoded_image_size

libheif/image-items/iden.h

This function in the `iden` (identity-derivation) item unconditionally returned success, bypassing size validation. This allowed a crafted `iden` item to declare a size different from the item it referenced, which was necessary to trigger the scaling operation on a mismatched image and cause the buffer overflow. The fix removes this override, enforcing proper size checks, as described in the advisory ('ImageItem_iden::check_decoded_image_size() unconditionally returns Error::Ok').

ImageItem::decode_image

libheif/image-items/image_item.cc

This function is responsible for decoding an image item. Before the patch, it used the declared size of an alpha image (`alpha_image`) for size comparisons, which could be manipulated by an attacker. The patch changes this to use the actual decoded size (`alpha`), ensuring that any scaling operations are based on correct dimensions. This is part of the broader fix for 'compare actual alpha size instead of declared size' (GHSA-2jg2-4ch7-h545, F02).