https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 07:32:14 +0000 https://vulnerability.circl.lu/vuln/ghsa-73rr-hh4g-fpgx <p><strong>Affected:</strong> npm: diff</p> <p>### Impact</p> <p>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.</p> <p>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).</p> <p>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.</p> <p>Finally, a second and lesser bug - a ReDOS - also exhibits when those same line break characters are present in a patch&#39;s *patch* header (also known as its &#34;leading garbage&#34;). A maliciously-crafted patch header of length *n* can take `parsePatch` O(*n*³) time to parse.</p> <p>### Patches</p> <p>All vulnerabilities described are fixed in v8.0.3.</p> <p>### Workarounds</p> <p>If using a version of jsdiff earlier than v8.0.3, do not attempt to parse patches that contain any of th…</p> <p><strong>Affected:</strong> npm: diff</p> <p>### Impact</p> <p>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.</p> <p>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).</p> <p>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.</p> <p>Finally, a second and lesser bug - a ReDOS - also exhibits when those same line break characters are present in a patch&#39;s *patch* header (also known as its &#34;leading garbage&#34;). A maliciously-crafted patch header of length *n* can take `parsePatch` O(*n*³) time to parse.</p> <p>### Patches</p> <p>All vulnerabilities described are fixed in v8.0.3.</p> <p>### Workarounds</p> <p>If using a version of jsdiff earlier than v8.0.3, do not attempt to parse patches that contain any of th…</p> https://vulnerability.circl.lu/vuln/ghsa-73rr-hh4g-fpgx