Marked version 3.0.0 introduces several dependency updates compared to version 2.1.3, potentially impacting developers relying on specific functionalities or versions of those dependencies. The core markdown parsing functionality remains consistent, focusing on speed and accuracy. However, developers should be aware of updated development dependencies, especially if contributing to the project or using tooling that leverages these dependencies.
Specifically, newer versions of eslint, rollup, jasmine, babel-core, markdown-it, highlight.js and babel-preset-env are included in v3.0.0. This could introduce changes in linting rules, bundling processes, testing behavior, javascript transpilation and syntax highlighting. Developers using these tools directly in their workflows should verify compatibility. Front-matter, semantic-release, eslint-plugin-node, vuln-regex-detector, rollup-plugin-license, eslint-config-standard and the semantic-release plugins remain on the same versions. However, there is a change in the rollup plugin for commonjs.
From a usage perspective, the core markdown parsing behavior of Marked should remain largely unchanged, offering a reliable and efficient solution for converting Markdown to HTML. The "description" field remains the same, emphasizing the library's focus on speed and efficiency. While the core javascript functionality should work as expected, it is always recommended to run tests to check for incompatibilities that could result due to the differences in the dependencies. The slight decrease in "unpackedSize" may indicate minor optimizations or refactoring within the library's codebase.
All the vulnerabilities related to the version 3.0.0 of the package
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: