Jsdoc version 3.5.0 represents a notable update over its predecessor, version 3.4.3, offering several key improvements for JavaScript developers seeking comprehensive API documentation. A significant change lies in its updated dependencies. Notably, version 3.5.0 upgrades babylon to ~7.0.0-beta.16, potentially enhancing its ability to parse modern JavaScript syntax. Conversely, version 3.4.3 relies on espree (~3.1.7) for parsing, which is absent in the newer release. The js2xmlparser dependency also sees an upgrade from ~1.0.0 to ~3.0.0 in version 3.5.0, potentially improving XML conversion capabilities. Further, bluebird sees an upgrade from version 3.4.6 to ~3.5.0 that enables the new version to support some new features for javascript Promises.
In terms of developer tooling, version 3.5.0 introduces nyc for test coverage reporting and updates gulp-eslint to ~4.0.0, suggesting a more modern linting setup, replacing istanbul used in version 3.4.3.
Developers considering an upgrade should evaluate the impact of the updated babylon parser on their codebase, as this could affect how JavaScript files are interpreted. The newer js2xmlparser could bring improved XML output, but compatibility should be verified. Also you should bear in mind that the updated versions of the dev dependencies may change the behaviour of your test and build pipelines. These changes collectively make version 3.5.0 a compelling upgrade, particularly for projects using newer JavaScript features and seeking enhanced documentation and testing workflows.
All the vulnerabilities related to the version 3.5.0 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:
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.
TaffyDB can allow access to any data items in the DB
TaffyDB allows attackers to forge adding additional properties into user-input processed by taffy which can allow access to any data items in the DB. Taffy sets an internal index for each data item in its DB. However, it is found that the internal index can be forged by adding additional properties into user-input. If index is found in the query, TaffyDB will ignore other query conditions and directly return the indexed data item. Moreover, the internal index is in an easily-guessable format (e.g., T000002R000001). As such, attackers can use this vulnerability to access any data items in the DB. Note: taffy and its successor package taffydb are not maintained.
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.