sharp : Vulnerability in librsvg dependency CVE-2026-96889

1. Executive summary

A memory-safety flaw in the upstream librsvg dependency shipped inside the sharp Node.js image-processing library can lead to remote code execution on glibc-based Linux under certain runtime conditions. CVE-2026-96889 carries a CVSS of 7.8 (HIGH) per the verified reference data, is not listed in CISA KEV, and has an EPSS of 0%. The affected component is reached when an application passes attacker-controlled SVG input to sharp; the GitHub advisory rates the issue 8.9 (High) under CVSS v4, which is a different scoring system from the 7.8 figure and is not a contradiction. EMEA financial services exposure is concentrated in server-side image pipelines (statement rendering, KYC document processing, thumbnail generation) that accept untrusted uploads. The immediate action is to upgrade sharp to 0.35.5 or librsvg to 2.63.2, or block SVG decoding entirely.

2. Regulatory framing

No NIS2 or UK NIS article is directly engaged by this item on the facts available. The advisory describes a library vulnerability and a fix; it does not report an incident, so the incident-reporting articles in the reference are not triggered.

3. Technical analysis & attack chain

The flaw is a use-after-free (CWE-416) in librsvg, the SVG rendering library that sharp loads through libvips. The verified reference data records CVE-2026-96889 at CVSS 7.8 (HIGH), not in CISA KEV, EPSS 0%. The GitHub advisory for the same CVE rates it 8.9 under CVSS v4 with an attack vector of Local and Attack Requirements set to Present; the two scores use different CVSS versions and both can describe the same defect. The advisory text calls it a "memory-related vulnerability" without naming the specific freed object or the exact trigger, so the precise corruption path is not public in the material reviewed here.

Confirmed steps in the exploitation path:

1. An application using sharp accepts an SVG image from an untrusted source and passes it to the image pipeline.
2. sharp hands the SVG to libvips, which loads it through the librsvg backend (the VipsForeignLoadSvg operation).
3. librsvg parses the SVG and hits the use-after-free condition. The advisory states this requires "certain runtime-specific conditions" but does not enumerate them.
4. On glibc-based Linux, the corruption can be turned into remote code execution. The advisory qualifies this as "possible" RCE.

The advisory does not describe initial access, persistence, privilege escalation, command-and-control, lateral movement, or data exfiltration. No malware, payload, or post-exploitation tooling is named. There are no file paths, registry keys, ports, or protocols beyond the libvips operation name VipsForeignLoadSvg. This is a library vulnerability disclosure, not a campaign report, and the absence of those stages reflects the source, not an omission in this advisory.

Two runtime conditions determine real exposure. First, the process must be running on glibc-based Linux; the advisory scopes the RCE impact to that platform. Second, the node executable must not be compiled as a Position Independent Executable. The advisory states that most Linux package managers ship PIE node binaries, but the "official" Node.js binaries do not, and a non-PIE node removes the hardening that would otherwise frustrate the RCE. An organisation running official Node.js binaries on glibc Linux and decoding untrusted SVG is the exposed case.

A related but separate advisory (GHSA-rgj7-g3m4-5g8c) covers libheif vulnerabilities in sharp prior to 0.35.4, including CVE-2026-84383. That is a different dependency and a different CVE; it is noted here only because clients upgrading sharp for the librsvg fix will also clear the libheif issues if they move to 0.35.5.

4. Mitigation & containment

P1 (within 24 hours)

• Upgrade sharp to 0.35.5, which bundles librsvg 2.63.2. This is the vendor fix for the prebuilt-binary path.
• Where librsvg is installed globally rather than bundled, upgrade librsvg to 2.63.2.
• If an immediate upgrade is not possible, block SVG decoding in application code: js sharp.block({ operation: ["VipsForeignLoadSvg"] }); This prevents sharp from reaching the vulnerable librsvg code path. Confirm the block is in place on every service that calls sharp, not only the primary image endpoint.
• Inventory which services accept SVG from untrusted sources. Any service that does is the priority for the two steps above.

P2 (within 72 hours)

• Check whether the node binary in use is compiled as a Position Independent Executable. The advisory states most Linux package managers ship PIE node, but official Node.js binaries do not. Where a non-PIE node is in use, replace it with a distribution-packaged build or rebuild with PIE. This is defence in depth: it does not fix the use-after-free but removes the conditions the advisory ties to RCE.
• Add librsvg and sharp to the software bill of materials and dependency-tracking process so transitive image libraries are visible to patch management.

P3 (within 7 days)

• Review whether any managed or outsourced image-processing service embeds sharp or librsvg, and confirm with the provider that it has moved to sharp 0.35.5 or librsvg 2.63.2.
• If the upgrade to 0.35.5 also clears the libheif issues in GHSA-rgj7-g3m4-5g8c, close those tickets in the same change.

5. Indicators of compromise

No indicators of compromise available in the source material. The advisory is a library vulnerability disclosure and provides no hashes, domains, IP addresses, file paths, or command lines.

The source describes one observable behaviour worth monitoring, but it is a configuration state rather than an atomic indicator.

No copyable indicator block is provided because there are no atomic indicators.

6. Detection

Insufficient indicators to author detection rules. The source material contains no distinctive strings, command-line flags, mutex names, file names, registry keys, or hard-coded values belonging to the threat. The only named artefact, VipsForeignLoadSvg, is a legitimate libvips operation name that appears in normal SVG decoding and would produce false positives across any environment that processes SVG. A rule built on it would detect the feature, not an attack.

CVE assessment

1 referenced CVE

7. Sources

• GitHub Security Advisories (npm), "sharp : Vulnerability in librsvg dependency CVE-2026-96889", https://github.com/advisories/GHSA-wq5f-xc86-pv6w, published 2026-10-06.
• GitHub Security Advisories (high+), "sharp: Vulnerabilities in libheif: GHSA-g89c-p67h-r497 and GHSA-2jg2-4ch7-h545", https://github.com/advisories/GHSA-rgj7-g3m4-5g8c.

8. Adverse Trace position

Adverse Trace assesses CVE-2026-96889 as a HIGH-severity (CVSS 7.8) local-condition vulnerability with no observed exploitation: it is not in CISA KEV and EPSS is 0%. The RCE impact is real but conditional on glibc-based Linux, a non-PIE node binary, and an application that decodes untrusted SVG, so the population of exposed clients is narrower than the raw severity suggests. The advisory is single-sourced to the GitHub Security Advisory; the CVSS v4 score of 8.9 and the "possible RCE" wording are the vendor's, and we have not independently reproduced the flaw. Clients running sharp in any pipeline that accepts external images should treat the upgrade to 0.35.5 as a P1 change and confirm the SVG block is active where upgrade is delayed. We will monitor for a public proof of concept, for any change to the KEV or EPSS status, and for reports of exploitation in image-processing services, and will reissue this advisory if the exploitation picture changes.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.