The marked npm package, a popular choice for speedy Markdown parsing, saw a small but potentially impactful update with the release of version 1.2.9, following the previous stable version 1.2.8. While the core functionality remains the same – providing developers with a fast and efficient way to convert Markdown into HTML – subtle changes in the development dependencies suggest improvements in tooling and build processes that can affect developers indirectly.
Specifically, version 1.2.9 reflects an updated development environment. Key changes involve upgrades to eslint (from 7.18.0 to 7.19.0), @rollup/plugin-babel (from 5.2.2 to 5.2.3), and @rollup/plugin-commonjs (from 17.0.0 to 17.1.0). These updates likely address bug fixes, performance enhancements, and potentially new features within these underlying development tools. Furthermore, uglify-js was updated (from 3.12.5 to 3.12.6).
While these alterations might not directly impact the runtime behavior of the marked library itself, they suggest a focus on maintaining a modern and well-supported development pipeline, which can lead to improved stability and faster iteration cycles, ultimately benefiting developers who rely on the package. The small increase in extracted size, from 266885 for v1.2.8 to 267216 for v1.2.9, indicates a small alteration in the compiled code.
All the vulnerabilities related to the version 1.2.9 of the package
Regular Expression Denial of Service (REDoS) in Marked
What kind of vulnerability is it? Who is impacted?
Regular expression Denial of Service
A Denial of Service attack can affect anyone who runs user generated code through marked.
Has the problem been patched? What versions should users upgrade to?
patched in v2.0.0
Is there a way for users to fix or remediate the vulnerability without upgrading?
None.
Are there any links users can visit to find out more?
https://github.com/markedjs/marked/issues/1927 https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
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 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: