All the vulnerabilities related to the version 12.2.0 of the package
Uncontrolled Resource Consumption in ansi-html
This affects all versions of package ansi-html. If an attacker provides a malicious string, it will get stuck processing the input for an extremely long time.
Uncontrolled resource consumption in braces
The NPM package braces fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In lib/parse.js, if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.
Server-Side Request Forgery (SSRF) in GitHub repository ionicabizau/parse-url
Server-Side Request Forgery (SSRF) in GitHub repository ionicabizau/parse-url prior to 8.1.0.
parse-url parses http URLs incorrectly, making it vulnerable to host name spoofing
parse-url prior to 8.1.0 is vulnerable to Misinterpretation of Input. parse-url parses certain http or https URLs incorrectly, identifying the URL's protocol as ssh. It may also parse the host name incorrectly.
Authorization Bypass in parse-path
Authorization Bypass Through User-Controlled Key in GitHub repository ionicabizau/parse-path prior to 5.0.0.
ReDOS vulnerabities: multiple grammars
The Regular expression Denial of Service (ReDoS) is a Denial of Service attack, that exploits the fact that most Regular Expression implementations may reach extreme situations that cause them to work very slowly (exponentially related to input size). An attacker can then cause a program using a Regular Expression to enter these extreme situations and then hang for a very long time.
If are you are using Highlight.js to highlight user-provided data you are possibly vulnerable. On the client-side (in a browser or Electron environment) risks could include lengthy freezes or crashes... On the server-side infinite freezes could occur... effectively preventing users from accessing your app or service (ie, Denial of Service).
This is an issue with grammars shipped with the parser (and potentially 3rd party grammars also), not the parser itself. If you are using Highlight.js with any of the following grammars you are vulnerable. If you are using highlightAuto to detect the language (and have any of these grammars registered) you are vulnerable. Exponential grammars (C, Perl, JavaScript) are auto-registered when using the common grammar subset/library require('highlight.js/lib/common') as of 10.4.0 - see https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@10.4.0/build/highlight.js
All versions prior to 10.4.1 are vulnerable, including version 9.18.5.
Grammars with exponential backtracking issues:
And of course any aliases of those languages have the same issue. ie: hpp is no safer than cpp.
Grammars with polynomial backtracking issues:
And again: any aliases of those languages have the same issue. ie: ruby and rb share the same ruby issues.
If you have any questions or comments about this advisory:
Regular Expression Denial of Service (ReDoS) in micromatch
The NPM package micromatch prior to version 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in micromatch.braces() in index.js because the pattern .* will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persisted prior to https://github.com/micromatch/micromatch/pull/266. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching.
Regular Expression Denial of Service in trim
All versions of package trim lower than 0.0.3 are vulnerable to Regular Expression Denial of Service (ReDoS) via trim().
Unsafe defaults in remark-html
The documentation of remark-html has mentioned that it was safe by default. In practise the default was never safe and had to be opted into. This means arbitrary HTML can be passed through leading to potential XSS attacks.
The problem has been patched in 13.0.2 and 14.0.1: remark-html is now safe by default, and the implementation matches the documentation.
On older affected versions, pass sanitize: true, like so:
- .use(remarkHtml)
+ .use(remarkHtml, {sanitize: true})
n/a
If you have any questions or comments about this advisory:
remark-htmlvue-template-compiler vulnerable to client-side Cross-Site Scripting (XSS)
A vulnerability has been discovered in vue-template-compiler, that allows an attacker to perform XSS via prototype pollution. The attacker could change the prototype chain of some properties such as Object.prototype.staticClass or Object.prototype.staticStyle to execute arbitrary JavaScript code. Vue 2 has reached End-of-Life. This vulnerability has been patched in Vue 3.
yargs-parser Vulnerable to Prototype Pollution
Affected versions of yargs-parser are vulnerable to prototype pollution. Arguments are not properly sanitized, allowing an attacker to modify the prototype of Object, causing the addition or modification of an existing property that will exist on all objects.
Parsing the argument --foo.__proto__.bar baz' adds a bar property with value baz to all objects. This is only exploitable if attackers have control over the arguments being passed to yargs-parser.
Upgrade to versions 13.1.2, 15.0.1, 18.1.1 or later.