Marked version 0.8.2 presents a subtle but notable evolution from its predecessor, version 0.8.1, primarily focused on refining the development environment and tooling rather than introducing core functional changes for end-users. Developers leveraging Marked will find the parsing behavior consistent across both versions, ensuring stable markdown processing. The key distinctions lie within the devDependencies, which highlight updated tool versions for tasks such as linting, bundling, and testing.
Specifically, eslint jumps from ^6.7.2 to ^6.8.0, rollup advances from ^1.27.11 to ^2.1.0, and @babel/core progresses from ^7.7.5 to ^7.9.0. These updates generally represent improvements in code quality checks, module bundling efficiency, and JavaScript transpilation capabilities potentially making the contribution process easier with better tooling support.
However, the change from eslint-plugin-node ^10.0.0 to ^11.0.0 and eslint-plugin-import ^2.19.1 to ^2.20.1 indicates stricter rules for Node.js code patterns and javascript module imports respectively. Also, eslint-config-standard goes from ^14.1.0 to ^14.1.1. These may affect contributing developers with updated linting rules and requirements. Front-matter is also updated from ^3.0.2 to ^3.1.0 meaning an updated version of the library can be used by contributors during development.
The file size also experienced a minor increase in the unpacked size, going from 190896 to 191332.
While version 0.8.2 isn't a revolutionary leap, its updated dependencies suggest an ongoing commitment to code quality, developer experience, and staying current with the rapidly evolving JavaScript ecosystem.
All the vulnerabilities related to the version 0.8.2 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: