CVE-2026-24001: 
JavaScript vulnerability analysis and mitigation

CVE-2026-24001 is a Denial of Service (DoS) vulnerability in the jsdiff JavaScript text differencing library (npm package diff) affecting the parsePatch and applyPatch methods. When a patch whose filename headers contain the line break characters \r, \u2028, or \u2029 is parsed, the parsePatch method enters an infinite loop and consumes memory without bound until the process crashes with an out-of-memory error. A secondary ReDoS (Regular Expression Denial of Service) vulnerability also exists when these characters appear in a patch's leading garbage header, causing O(n³) parse time. Affected versions include all releases prior to 3.5.1, 4.0.0–4.0.3, 5.0.0–5.2.1, and 6.0.0–8.0.2. The vulnerability was published on January 22, 2026, with a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, IBM Advisory).

The root cause is an inconsistency between two regular expressions used in the parsePatch function (CWE-400: Uncontrolled Resource Consumption; CWE-1333: Inefficient Regular Expression Complexity). The line-detection regex /^(Index:\s|diff\s|---\s|\+\+\+\s|===...)/.test(line) matches lines beginning with --- even when the filename contains \u2028 (a Unicode line separator not matched by . in JavaScript regexes), causing the parser to break out of its inner loop. However, the subsequent parseFileHeader regex /^(---|\+\+\+)\s+(.*)\r?$/ fails to match the same line because .* does not match \u2028, leaving the line unconsumed. The outer parsePatch loop then calls parseIndex again on the same line indefinitely, growing an internal list until the process runs out of memory (GitHub PR #649, GitHub Advisory). The applyPatch method is also affected because it internally calls parsePatch when given a string argument. No authentication or large payload is required — a minimal crafted patch string (e.g., '--- x\u2028x') is sufficient to trigger the crash.

Successful exploitation causes the affected Node.js process to enter an infinite loop, consuming all available heap memory until it crashes with a fatal out-of-memory error, resulting in complete denial of service for the application. There is no confidentiality or integrity impact — only availability is affected. Applications that expose parsePatch or applyPatch to user-controlled input over a network are at highest risk, and even applications processing self-generated patches may be vulnerable if users can influence filename headers. The attack requires no authentication and no large payload, making input size restrictions ineffective as a mitigation (GitHub Advisory, IBM Advisory).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The vulnerability is unauthenticated and network-reachable with low attack complexity, requiring no user interaction. The EPSS score is approximately 0.042% (low probability of near-term exploitation). The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Identify a target application: Find a web application or service that uses the diff npm package (jsdiff) and exposes parsePatch or applyPatch functionality to user-controlled input — for example, a code review tool, patch upload endpoint, or diff viewer.
2. Craft a malicious patch string: Construct a minimal patch string containing a filename header with a Unicode line separator character. For example: '--- x\u2028x' or '--- filename\r\nmore'. The key is embedding \r, \u2028, or \u2029 in the filename portion of the --- or +++ header line.
3. Submit the malicious patch: Send the crafted patch string to the target endpoint — via HTTP POST body, file upload, API call, or any other input vector that passes the string to parsePatch or applyPatch.
4. Trigger the infinite loop: The parsePatch function enters an infinite loop because the line-detection regex matches the crafted line but the parseFileHeader regex does not, leaving the line unconsumed and causing the outer loop to repeat indefinitely.
5. Achieve denial of service: The Node.js process continuously allocates memory for the growing internal list until heap exhaustion triggers a fatal OOM crash, taking the application offline (GitHub PR #649, GitHub Advisory).

• Process Behavior: Node.js process exhibiting rapidly increasing heap memory consumption without bound; process terminating with FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory.
• Logs: Application crash logs or Node.js stderr output containing JavaScript heap out of memory or Aborted (core dumped) messages; repeated or hung requests to patch-parsing endpoints in web server access logs.
• Network: Unusual or repeated HTTP requests to endpoints that accept patch file input (e.g., diff upload, code review, or patch apply endpoints) containing non-standard line break characters (\r, \u2028, \u2029) in request bodies.
• System: Sudden process restarts or container/pod restarts for services using the diff npm package; monitoring alerts for memory exhaustion on Node.js services.

Update the diff npm package (jsdiff) to one of the following patched versions: 3.5.1 (for the 3.x branch), 4.0.4 (for the 4.x branch), 5.2.2 (for the 5.x branch), or 8.0.3 (for the 6.x/8.x branch). The fix was merged on January 7, 2026, and corrects the regex inconsistency so that parsePatch reliably processes lines in linear time (GitHub Commit, GitHub Advisory). As a temporary workaround if immediate patching is not possible, validate and reject any user-provided patch input containing the characters \r, \u2028, or \u2029 before passing it to parsePatch or applyPatch. Additionally, implement process-level memory limits and automatic restart policies to reduce the impact of a successful DoS attempt. IBM has released updated advisories for affected products including IBM Storage Defender, IBM Event Processing, IBM Cloud Pak for Integration, IBM DevOps Solution Workbench, IBM watsonx Orchestrate, and IBM QRadar Suite Software (IBM Advisory).

The vulnerability was reported by researcher guiyi-he and remediated by ExplodingCabbage (a jsdiff collaborator), who authored the fix and provided a detailed technical explanation in the pull request (GitHub PR #649). The issue generated notable downstream activity, with multiple popular projects — including AstroJS, Facebook's balance, Sentry JavaScript SDK, and AWS Lambda base images — filing issues or PRs to update their jsdiff dependency. Community discussion noted that the v4.x branch is particularly widely used (e.g., via ts-node), prompting a backport request (GitHub Issue #653). IBM issued multiple security bulletins across its product portfolio acknowledging the vulnerability.