Marked version 0.3.17 introduces notable development dependencies focused on code quality and standardization, representing an upgrade from the 0.3.16 release. While both versions maintain the core functionality of a fast markdown parser under the MIT license and share the same author and repository, the newer version incorporates ESLint and related plugins to enforce code style and best practices. Developers using version 0.3.17 will benefit from pre-configured linting rules designed to catch potential errors and maintain code consistency. These dependencies include eslint, eslint-plugin-node, eslint-plugin-import, eslint-plugin-promise, eslint-config-standard, and eslint-plugin-standard.
These additions suggest a focus on improving the maintainability and long-term stability of the Marked library. By adhering to the Standard JavaScript style guide and employing ESLint's static analysis, the developers of Marked aim to minimize bugs and facilitate collaboration. Version 0.3.17 also has a higher file count (21 vs 16) and unpacked size (89614 vs 77481) reflecting the inclusion of these new development dependencies. For developers contributing to the Marked project or seeking to integrate it into projects with strict code quality requirements, version 0.3.17 offers a more robust and standardized development environment. It's a clear step towards streamlined workflows and increased code reliability.
All the vulnerabilities related to the version 0.3.17 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: