CVE-2026-24001
Infinite Loop and ReDOS in jsdiff parsePatch Causing DoS
Publication date: 2026-01-22
Last updated on: 2026-03-04
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| kpdecker | jsdiff | to 3.5.1 (exc) |
| kpdecker | jsdiff | From 4.0.0 (inc) to 4.0.4 (exc) |
| kpdecker | jsdiff | From 5.0.0 (inc) to 5.2.2 (exc) |
| kpdecker | jsdiff | From 6.0.0 (inc) to 8.0.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-1333 | The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles. |
| CWE-400 | The product does not properly control the allocation and maintenance of a limited resource. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-24001 is a denial-of-service (DoS) vulnerability in the jsdiff JavaScript library's parsePatch and applyPatch methods. When these methods parse patch files whose filename headers contain certain line break characters (carriage return \r, Unicode line separator \u2028, or paragraph separator \u2029), parsePatch can enter an infinite loop. This causes unbounded memory consumption, eventually crashing the process due to out-of-memory errors. Additionally, a related Regular Expression Denial of Service (ReDoS) vulnerability causes the parsing time to increase cubically with the length of a malicious patch header. These issues allow attackers to cause excessive CPU and memory usage, leading to DoS. The vulnerability affects versions prior to 8.0.3, 5.2.2, and 4.0.4, and has been fixed in those versions. The root cause involves inconsistent regex handling and flawed parsing logic around these special characters. [1, 2, 3]
How can this vulnerability impact me? :
This vulnerability can impact you by allowing an attacker to cause a denial-of-service condition in applications using the vulnerable versions of the jsdiff library. Specifically, if your application calls parsePatch or applyPatch with user-supplied patch data containing the problematic line break characters, the library may enter an infinite loop and consume unlimited memory, leading to a crash of the Node.js process. This can disrupt service availability and potentially cause downtime. The vulnerability can be triggered with relatively small inputs, so input size limits do not protect against it. Even applications generating patches internally may be vulnerable if users can influence filename headers. Therefore, the impact is primarily service unavailability due to resource exhaustion. [1, 2]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for applications using vulnerable versions of the jsdiff library (versions >=4.0.0 and <4.0.4, >=5.0.0 and <5.2.2, and >=6.0.0 and <8.0.3) that parse patches containing the problematic line break characters \r, \u2028, or \u2029 in filename headers. Detection can involve checking logs or application inputs for patches containing these characters. Since the vulnerability causes infinite loops and high memory consumption, monitoring for unusually high CPU or memory usage in processes using jsdiff's parsePatch or applyPatch methods can also indicate exploitation attempts. Specific commands are not provided in the resources, but general approaches include searching patch inputs for these characters (e.g., using grep or similar tools) and monitoring process resource usage (e.g., using top, ps, or system monitoring tools). [1, 2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading the jsdiff library to version 8.0.3 or later (or patched versions 5.2.2 and 4.0.4) where the vulnerability is fixed. As a workaround, avoid parsing patches that contain the line break characters \r, \u2028, or \u2029 in filename headers. Additionally, ensure that applications do not accept or process user-supplied patches with these characters. Monitoring and restricting inputs to the parsePatch and applyPatch methods can help prevent exploitation until the upgrade is applied. [1, 2, 3]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided resources do not contain information regarding the impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.