Jsdoc version 3.3.0 represents a significant update from the older 3.2.2, offering developers a more modern and streamlined JavaScript API documentation generator. One notable shift is in dependency management. The newer version embraces more recent iterations of key libraries like async, marked, and underscore, ensuring compatibility with current JavaScript ecosystems. Crucially, specific Git repository dependencies in 3.2.2 like taffydb and crypto-browserify are replaced in 3.3.0 with potentially more stable and easily manageable tarball references for esprima and taffydb, streamlining the installation process and reducing reliance on live repositories and potential breaking changes. The introduction of development dependencies such as gulp, eslint, istanbul, gulp-eslint, and gulp-json-editor in 3.3.0 highlights a commitment to enhanced code quality, automated testing (including code coverage analysis with Istanbul), and streamlined build processes, making it easier for developers to contribute and maintain the JSDoc project itself, and also provides tooling hints for developers looking to integrate jsdoc documentation generation into their own build processes. The reliance on jshint in the older version is replaced by eslint, indicating a move toward more modern and configurable linting standards. Overall, the upgrade to 3.3.0 offers a more robust, maintainable, and developer-friendly experience.
All the vulnerabilities related to the version 3.3.0 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.