# CVE-2026-24001: diff DoS — Fixed in 8.0.3 📦 npm Not in CISA KEV # CVE-2026-24001 — diff [Fix: kpdecker/jsdiff@15a1585](https://github.com/kpdecker/jsdiff/commit/15a1585230748c8ae6f8274c202e0c87309142f5) CVE-2026-24001 is a Uncontrolled Resource Consumption vulnerability in diff. A fix is available for diff — see the affected versions and patch details below. jsdiff has a Denial of Service vulnerability in parsePatch and applyPatch Also known as[GHSA-73rr-hh4g-fpgx](/vulnerability/GHSA-73rr-hh4g-fpgx) Published Jan 22, 2026 Updated Nov 7, 2026 Affected 4 pkgs Patched 4 / 4 Exploits None indexed Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS) ## Exploitation Status ### No confirmed exploitation observed yet - CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks. - CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment. Exploitation and automatability from CISA’s SSVC triage for CVE-2026-24001. ## EPSS Exploitation Probability [via FIRST.org ↗](https://www.first.org/epss/) 0.6%probability of exploitation in next 30 days Lower Risk0.00% Lower risk than most CVEs50th percentile — riskier than 50% of all scored CVEsHighest risk 0.00%0.38%0.75%1.13%0.0%0.6%May 26Sep 26Nov 26 Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/). ## Real-World Exposure 4 pkgs affected 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. 11Kother npm packages depend on this — each one inherits the vulnerability until it's patched upstream `diff`npm 186.2Mdownloads / week ## Description #### Impact Attempting to parse a patch whose filename headers contain the line break characters `\r`, `\u2028`, or `\u2029` can cause the `parsePatch` method to enter an infinite loop. It then consumes memory without limit until the process crashes due to running out of memory. Applications are therefore likely to be vulnerable to a denial-of-service attack if they call `parsePatch` with a user-provided patch as input. A large payload is not needed to trigger the vulnerability, so size limits on user input do not provide any protection. Furthermore, some applications may be vulnerable even when calling `parsePatch` on a patch generated by the application itself if the user is nonetheless able to control the filename headers (e.g. by directly providing the filenames of the files to be diffed). The `applyPatch` method is similarly affected if (and only if) called with a string representation of a patch as an argument, since under the hood it parses that string using `parsePatch`. Other methods of the library are unaffected. Finally, a second and lesser bug - a ReDOS - also exhibits when those same line break characters are present in a patch's _patch_ header (also known as its "leading garbage"). A maliciously-crafted patch header of length _n_ can take `parsePatch` O(_n_³) time to parse. #### Patches All vulnerabilities described are fixed in v8.0.3. #### Workarounds If using a version of jsdiff earlier than v8.0.3, do not attempt to parse patches that contain any of these characters: `\r`, `\u2028`, or `\u2029`. #### References PR that fixed the bug: [https://github.com/kpdecker/jsdiff/pull/649](https://github.com/kpdecker/jsdiff/pull/649) #### CVE Notes Note that although the advisory describes two bugs, they each enable exactly the same attack vector (that an attacker who controls input to `parsePatch` can cause a DOS). Fixing one bug without fixing the other therefore does not fix the vulnerability and does not provide any security benefit. Therefore we assume that the bugs cannot possibly constitute Independently Fixable Vulnerabilities in the sense of CVE CNA rule 4.2.11, but rather that this advisory is properly construed under the rules as describing a single Vulnerability. ## Affected Packages 4 total 4 fixed Ecosystem Package Vulnerable range Fix 📦npm `diff` ≥ 6.0.0&&< 8.0.3 8.0.3`npm install diff@8.0.3` 📦npm `diff` ≥ 5.0.0&&< 5.2.2 5.2.2`npm install diff@5.2.2` 📦npm `diff` ≥ 4.0.0&&< 4.0.4 4.0.4`npm install diff@4.0.4` 📦npm `diff` all versions 3.5.1`npm install diff@3.5.1` ## Affected Products 1 product · 4 configurations Application `jsdiff`kpdecker ≥ 6.0.0 && < 8.0.3 range ## Detection & mitigation playbook Open-source dependency 1. ### Detect Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for diff, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version. 2. ### Fix Update diff to 8.0.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-24001 is resolved across your whole dependency graph. 3. ### Workarounds Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service. ## Fixing This On Your OS If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project. Red HatImportant Applications using the parsePatch and the applyPatch methods to process patches provided by user input are vulnerable to this issue. Specifically, specially crafted patch input with line break characters such as \\r, \\u2028, or \\u2029 can cause an infinite loop, excessive resource consumption and application crashes.… Workaround published by Red Hat > To mitigate this flaw, applications parsing user-supplied patch data should implement input validation to detect and reject input containing line break characters, such as \\r, \\u2028, or \\u2029 before passing the input to the parsePatch and the applyPatch methods, preventing the library from entering an infinite loop and consuming excessive memory. Source: [Red Hat security advisory for CVE-2026-24001](https://access.redhat.com/security/cve/cve-2026-24001) (CC BY 4.0) ## Frequently Asked Questions \### Impact Attempting to parse a patch whose filename headers contain the line break characters \`\\r\`, \`\\u2028\`, or \`\\u2029\` can cause the \`parsePatch\` method to enter an infinite loop. It then consumes memory without limit until the process crashes due to running out of memory. Applications are therefore likely to be vulnerable to a denial-of-service attack if they call \`parsePatch\` with a user-provided patch as input. A large payload is not needed to trigger the vulnerability, so size limits on user input do not provide any protection. Furthermore, some applications may be vulnerable even w O3 Security · Impact-Aware SCA ### Is CVE-2026-24001 in your dependencies? Find it across npm, including transitive dependencies. [Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)