Marked is a popular and fast markdown parsing library designed for speed and flexibility. Comparing version 0.3.9 and its predecessor, 0.3.7, reveals subtle yet potentially impactful changes for developers. Both versions share the same core purpose: efficiently converting markdown syntax into HTML. They also maintain identical development dependencies, relying on tools like Gulp for build processes, markdown and showdown for comparative testing, and gulp-concat and gulp-uglify for minimizing and combining files. Both versions use the MIT License and are authored by Christopher Jeffrey with source code managed on GitHub.
The key difference lies in their release dates. Version 0.3.9 was published on December 23, 2017, whereas version 0.3.7 was released on December 1, 2017,. This gap suggests that version 0.3.9 likely contains bug fixes, performance improvements, or very minor feature enhancements implemented after the earlier release. With no major version changes from version 0.3.7, developers already using the package should find upgrading to version 0.3.9 smooth, though careful testing is always recommended. New users looking for a reliable markdown parser can benefit from the library, knowing that both versions are mature and well-established. Always prioritizing the most recent patch version within the minor release can help improve the code's resilience and stability.
All the vulnerabilities related to the version 0.3.9 of the package
Marked allows Regular Expression Denial of Service (ReDoS) attacks
Marked prior to version 0.3.17 is vulnerable to a Regular Expression Denial of Service (ReDoS) attack due to catastrophic backtracking in several regular expressions used for parsing HTML tags and markdown links. An attacker can exploit this vulnerability by providing specially crafted markdown input, such as deeply nested or repetitively structured brackets or tag attributes, which cause the parser to hang and lead to a Denial of Service.
Inefficient Regular Expression Complexity in marked
What kind of vulnerability is it?
Denial of service.
The regular expression inline.reflinkSearch may cause catastrophic backtracking against some strings.
PoC is the following.
import * as marked from 'marked';
console.log(marked.parse(`[x]: x
\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](\\[\\](`));
Who is impacted?
Anyone who runs untrusted markdown through marked and does not use a worker with a time limit.
Has the problem been patched?
Yes
What versions should users upgrade to?
4.0.10
Is there a way for users to fix or remediate the vulnerability without upgrading?
Do not run untrusted markdown through marked or run marked on a worker thread and set a reasonable time limit to prevent draining resources.
Are there any links users can visit to find out more?
If you have any questions or comments about this advisory:
Inefficient Regular Expression Complexity in marked
What kind of vulnerability is it?
Denial of service.
The regular expression block.def may cause catastrophic backtracking against some strings.
PoC is the following.
import * as marked from "marked";
marked.parse(`[x]:${' '.repeat(1500)}x ${' '.repeat(1500)} x`);
Who is impacted?
Anyone who runs untrusted markdown through marked and does not use a worker with a time limit.
Has the problem been patched?
Yes
What versions should users upgrade to?
4.0.10
Is there a way for users to fix or remediate the vulnerability without upgrading?
Do not run untrusted markdown through marked or run marked on a worker thread and set a reasonable time limit to prevent draining resources.
Are there any links users can visit to find out more?
If you have any questions or comments about this advisory: