Bug 2431930 (CVE-2026-24001)

Summary: CVE-2026-24001 jsdiff: denial of service vulnerability in parsePatch and applyPatch
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: abuckta, anthomas, caswilli, dkuc, ehelms, ggainey, juwatts, kaycoth, mhulan, mstipich, nmoumoul, orabin, osousa, pcreech, rchan, rexwhite, smallamp, sthirugn, tmalecek
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in jsdiff. A specially crafted patch input containing specific line break characters can cause the parsePatch method to enter an infinite loop, leading to uncontrolled memory consumption and a process crash, resulting in a denial of service. The applyPatch method is similarly affected when called with a string representation of a patch as an argument. Additionally, a related vulnerability allows a Regular Expression Denial of Service (ReDoS) when these characters are present in a patch filename header, significantly increasing parsing time.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-01-22 03:01:46 UTC 
jsdiff is a JavaScript text differencing implementation. Prior to versions 8.0.3, 5.2.2, and 4.0.4, 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 interdependent 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. Versions 8.0.3, 5.2.2, and 4.0.4 contain a fix. As a workaround, do not attempt to parse patches that contain any of these characters: `\r`, `\u2028`, or `\u2029`.