Marked version 0.5.2 represents a minor update to the previous stable version, 0.5.1, of this popular markdown parsing library. Both versions share the same core description: a markdown parser built for speed, targeting developers who need efficient and reliable markdown-to-HTML conversion. From a development dependency perspective, the suite of tools remains consistent, featuring ESLint for code linting, Jasmine for testing, and utilities such as Uglify-js, markdown-it and commonmark for code quality.
The most noticeable differences lie in the "dist" section. Version 0.5.2 has a smaller fileCount (8 vs 16) and a slightly smaller unpackedSize (77479 bytes vs 77514 bytes) compared to version 0.5.1. This suggests that 0.5.2 might contain optimizations like file merging or removal of unnecessary files, potentially leading to a slightly smaller footprint when including the library in a project. The release date also pinpoints the newness of v0.5.2 (November 20, 2018) compared to v0.5.1 (September 26, 2018). So, developers will like the package because of the optimizations and recent release of 0.5.2. Choosing between two versions, using the latest (0.5.2) is mostly preferable given the optimizations stated before.
All the vulnerabilities related to the version 0.5.2 of the package
Marked ReDoS due to email addresses being evaluated in quadratic time
Versions of marked from 0.3.14 until 0.6.2 are vulnerable to Regular Expression Denial of Service. Email addresses may be evaluated in quadratic time, allowing attackers to potentially crash the node process due to resource exhaustion.
Upgrade to version 0.6.2 or later.
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: