Marked versions 0.5.0 and 0.4.0 are both iterations of a markdown parser renowned for its speed, aimed at developers needing efficient text processing. Examining the developer tool dependencies reveals consistency between the versions. Both rely on the same suite of tools for linting, testing, and minification, including ESLint, Jasmine, UglifyJS, and a host of ESLint plugins for code quality and security checks. The core license, repository, and author information also remain unchanged.
Key differences emerge when looking at the dist object and release date. Version 0.5.0, released on August 16, 2018, lists fileCount as 16 and unpackedSize as 75657, while version 0.4.0, released on May 21, 2018, has a fileCount of 17 and an unpackedSize of 76469. This suggests a slight reduction in file count and overall size in version 0.5.0. Developers might find the newer version slightly more streamlined, potentially leading to faster installation or reduced disk space usage. Furthermore, the 3-month gap between releases implies bug fixes or minor improvements incorporated into version 0.5.0. Users should consider these subtle changes when choosing between the two, prioritizing either the slightly smaller footprint of version 0.5.0 or the potentially longer track record of version 0.4.0. Both offer the same core markdown parsing functionality celebrated for its speed, under the permissive MIT license.
All the vulnerabilities related to the version 0.5.0 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: