Marked version 0.6.1 represents a minor update over its predecessor, 0.6.0, in this popular markdown parsing library renowned for its speed. Developers considering an upgrade should primarily focus on the adjustments made to the development dependencies. The newer version incorporates updates to several key tools within the development environment.
Specifically, eslint jumps from version 4.19.1 to 5.12.0, indicating potential refinements in code linting and style enforcement. Uglify-js sees a small bump from 3.4.8 to 3.4.9, suggesting minor bug fixes or performance improvements. A notable update is seen in front-matter, transitioning from version 2.3.0 to 3.0.1, likely introducing new features or breaking changes related to front matter parsing that developers should investigate. Glob-to-regexp also updates from 0.3.0 to 0.4.0.
Furthermore, eslint-plugin-node moves from 5.2.1 to 8.0.1, eslint-plugin-promise evolves from 3.8.0 to 4.0.1, eslint-config-standard shifts from 11.0.0 to 12.0.0, and eslint-plugin-standard progresses from 3.1.0 to 4.0.0, cumulatively these indicate an updated and more robust approach to code quality and adherence to standards. The core functionality of marked as a markdown parser remains largely unchanged in this incremental release, making the update primarily relevant to developers who actively contribute to the marked project or those who benefit from the improved development tooling during their markdown processing workflows.
All the vulnerabilities related to the version 0.6.1 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: