jsdiff is a JavaScript text differencing implementation. Prior to versions 8.0.3, 5.2.2, 4.0.4, and 3.5.1, 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, 4.0.4, and 3.5.1 contain a fix. As a workaround, do not attempt to parse patches that contain any of these characters: `\r`, `\u2028`, or `\u2029`.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - jsdiff is a JavaScript text differencing implementation. Prior to versions 8.0.3, 5.2.2, 4.0.4, and 3.5.1,     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, 4.0.4, and 3.5.1     contain a fix. As a workaround, do not attempt to parse patches that contain any of these characters:
    `\r`, `\u2028`, or `\u2029`. (CVE-2026-24001)

Note that Nessus relies on the presence of the package as reported by the vendor.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - jsdiff is a JavaScript text differencing implementation. Prior to versions 8.0.3, 5.2.2, 4.0.4, and 3.5.1,
    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, 4.0.4, and 3.5.1
    contain a fix. As a workaround, do not attempt to parse patches that contain any of these characters:
    `\r`, `\u2028`, or `\u2029`. (CVE-2026-24001)

ID	Name	Product	Family	Type	Severity
296224	Linux Distros Unpatched Vulnerability : CVE-2026-24001	Nessus	Misc.	Local	medium
436765	SCA: security update for diff (GHSA-73rr-hh4g-fpgx)	Tenable Cloud Security	SCA Checks	Local	medium
436765	SCA: security update for diff (GHSA-73rr-hh4g-fpgx)	Tenable Self-Hosted Container Security	SCA Checks	Local	medium

Detections

Analytics

CVE-2026-24001

medium

Tenable Plugins

medium

medium

medium