Marked version 0.3.19 represents a minor update over its predecessor, version 0.3.18, in this popular markdown parsing library. Both versions maintain the core promise of a fast and efficient markdown-to-HTML conversion, offering a robust solution for developers integrating markdown rendering into their applications. Functionally, the two versions appear identical in terms of declared development dependencies, including tools like ESLint for code linting, Jasmine for testing, and various markdown comparison libraries like Markdown-it and Showdown. They both employ similar tooling and configurations for maintaining code quality and facilitating testing.
The key difference lies in the package metadata. Version 0.3.19 shows an increase in the unpacked size (80609) and the number of files included in the distribution (19). The previous version, 0.3.18, had an unpacked size of 66263 and 16 files. This suggests that version 0.3.19 may incorporate bug fixes, performance improvements, documentation updates, or new features that account for the added size. The release date also points towards a very close window between versions, with version 0.3.19 being released just a few days after version 0.3.18. Developers considering an upgrade should examine the changelog (typically available on the project's GitHub repository) for specific details on these changes to assess their impact on existing implementations. Since the differences are very small we can assume that the upgrade from 0.3.18 to 0.3.19 should be pretty straightforward and is advisable.
All the vulnerabilities related to the version 0.3.19 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.
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: