Jsdoc is a widely used API documentation generator for JavaScript, and examining versions 3.3.2 and 3.3.1 reveals subtle yet important differences beneficial to developers. Both versions share the same core dependencies, including crucial libraries like Async for asynchronous operations, Marked for Markdown parsing, and Esprima for ECMAScript parsing. They also leverage Taffydb for in-memory database functionalities and Catharsis for parsing JSDoc types. The development dependencies remain consistent, featuring tools like Gulp for task automation, ESLint for code linting, and Istanbul for code coverage analysis, ensuring code quality and maintainability.
The key distinction lies in the release date. Version 3.3.2 was released on June 13, 2015, while version 3.3.1 was released on June 7, 2015. While this difference may seem minor, it suggests that version 3.3.2 likely contains bug fixes, performance improvements, or minor feature enhancements implemented in the intervening week. For developers seeking the most stable and up-to-date experience, opting for version 3.3.2 is advisable. Both versions benefit from the "Apache-2.0" license, offering flexibility in usage and modification. Jsdoc's solid dependency base, alongside quality assurance via its development dependencies, makes it a reliable choice for generating comprehensive API documentation, and the newer release typically represents a more refined and robust option.
All the vulnerabilities related to the version 3.3.2 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.