Marked is a popular and speedy Markdown parser designed for developers who need a reliable solution for converting Markdown text into HTML. Comparing versions 0.8.1 and 0.8.0 reveals subtle yet important changes for users of the library. Both versions share identical development dependencies, including tools for linting, bundling, testing, and vulnerability detection, indicating a consistent development pipeline. Key dependencies like eslint, rollup, cheerio, and @babel/core remain at the same versions, signifying stability in the core toolchain. Both versions are licensed under the MIT license, ensuring flexibility for developers integrating Marked into various projects.
The primary differences between the versions are in their build and release characteristics. Version 0.8.1 was released on March 18, 2020, while version 0.8.0 was released significantly earlier on December 12, 2019. This temporal gap suggests potential bug fixes, performance improvements, or minor feature enhancements in the newer version. Furthermore, version 0.8.1 has a slightly larger unpacked size (190896 bytes) than version 0.8.0 (186311 bytes), despite having the same number of files (19). This small increase in size could point to adjustments in the core parsing logic or the inclusion of additional assets. Developers should consider upgrading to version 0.8.1 to benefit from the latest refinements and potentially improved performance. The consistent use of development dependencies ensures a familiar environment for contributors and promotes long-term maintainability. Using this library grants you the peace of mind of having a parser battle-tested and actively maintained.
All the vulnerabilities related to the version 0.8.1 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: