Jsdoc, a popular API documentation generator for JavaScript, released version 3.3.3 as a minor update following version 3.3.2. Both versions maintain the core functionality of generating documentation from JSDoc-style comments within JavaScript code. Developers using Jsdoc can automatically create comprehensive API documentation, improving code maintainability and collaboration.
A key difference between the two versions lies in the dependency on Esprima. Version 3.3.2 relied on a specific commit of Esprima directly from GitHub, while version 3.3.3 updated this dependency to version 1.2.5, potentially incorporating bug fixes and performance improvements within the Esprima parser. This is relevant for developers concerned with the accuracy and speed of the documentation generation process, especially when dealing with complex JavaScript code.
Both versions share a common set of dependencies, which ensure consistent documentation generation. These dependencies include Async, Marked, and Catharsis. Developers might also be interested in the inclusion of development dependencies like ESLint, Gulp, and Istanbul, which indicates a commitment to code quality and testing practices within the JSDoc project itself.
For developers, the update from 3.3.2 to 3.3.3 signifies more than just a version number; it suggests a refined and potentially more reliable documentation generation experience. Developers should update to version 3.3.3, especially if the previous version caused issues with code parsing.
All the vulnerabilities related to the version 3.3.3 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:
Arbitrary Code Execution in underscore
The package underscore from 1.13.0-0 and before 1.13.0-2, from 1.3.2 and before 1.12.1 are vulnerable to Arbitrary Code Execution via the template function, particularly when a variable property is passed as an argument as it is not sanitized.