Marked versions 0.6.3 and 0.6.2, both described as "A markdown parser built for speed," showcase incremental updates geared towards developers seeking a reliable and performant Markdown processing solution. While both share the same core functionality and MIT license, subtle differences in their development dependencies reveal key improvements.
Version 0.6.3, released on June 30, 2019, demonstrates updates in its tooling. Most notably the eslint package was upgraded, alongside an increase in Jasmine and addition of node-fetch. Developers leveraging these updates should find 0.6.3 incorporates enhanced code quality checks and streamlined testing, which can lead to fewer bugs and a more robust Markdown parsing experience.
Compared to version 0.6.2, released in April 2019, which used older versions of the listed tools, the newer release signals a commitment to keeping the project's build and test environment up-to-date, thus ensuring compatibility with the latest developer tools and best practices and more robust external data fetching. Consequently, developers integrating Marked into their projects, especially those relying on modern tooling, might find version 0.6.3 a more seamless fit. This iterative approach to dependency management and improvements makes Marked a valuable option for both experienced and new users of markdown parsing libraries. Despite the subtle differences, the core promise of speed and accurate markdown parsing remains constant between versions 0.6.2 and 0.6.3.
All the vulnerabilities related to the version 0.6.3 of the package
Regular Expression Denial of Service in marked
Affected versions of marked are vulnerable to Regular Expression Denial of Service (ReDoS). The _label subrule may significantly degrade parsing performance of malformed input.
Upgrade to version 0.7.0 or later.
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: