sharp : Vulnerability in librsvg dependency CVE-2026-96889GHSA-wq5f-xc86-pv6w
Fix: lovell/sharp@96de105GHSA-wq5f-xc86-pv6w is a Use After Free vulnerability in sharp. A fix is available for sharp — see the affected versions and patch details below.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
sharpnpmDescription
Impact
A memory-related vulnerability has been discovered and fixed in the upstream librsvg dependency. When certain runtime-specific conditions apply, this vulnerability can lead to possible remote code execution (RCE) on glibc-based Linux.
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.5, which provides librsvg 2.63.2.
Using a globally-installed librsvg?
Please ensure you are using the latest librsvg 2.63.2.
Workarounds
Add the following to your code to prevent sharp from decoding SVG images.
sharp.block({ operation: ["VipsForeignLoadSvg"] });
To avoid RCE, ensure you are using a node executable binary compiled as a Position Independent Executable (PIE). Most Linux package managers already use this security-hardening feature however be warned that the "official" Node.js binaries do not.
1
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | sharp | all versions | 0.35.5npm install sharp@0.35.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for sharp, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update sharp to 0.35.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-wq5f-xc86-pv6w is resolved across your whole dependency graph.
Workarounds
Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.
Frequently Asked Questions
Is GHSA-wq5f-xc86-pv6w in your dependencies?
Find it across npm, including transitive dependencies.