vulnerabilities in npm dependencies

ugh, npm.

There are 100 npm security advisories affecting our repositories.

#1002492: immer (CVE-2021-23436)

Severity: critical

This affects the package immer before 9.0.6. A type confusion vulnerability can lead to a bypass of CVE-2020-28477 when the user-provided keys used in the path parameter are arrays. In particular, this bypass is possible because the condition (p === "proto" || p === "constructor") in applyPatches_ returns false if p is ['proto'] (or ['constructor']). The === operator (strict equality operator) returns false if the operands have different type.

Affected repositories (4)

#1002656: xmlhttprequest-ssl (CVE-2021-31597)

Severity: critical

The xmlhttprequest-ssl package before 1.6.1 for Node.js disables SSL certificate validation by default, because rejectUnauthorized (when the property exists but is undefined) is considered to be false within the https.request function of Node.js. In other words, no certificate is ever rejected.

Affected repositories (1)

#1002809: handlebars (CVE-2021-23369)

Severity: critical

The package handlebars before 4.7.7 are vulnerable to Remote Code Execution (RCE) when selecting certain compiling options to compile templates coming from an untrusted source.

Affected repositories (1)

#1004593: cryptiles (CVE-2018-1000620)

Severity: critical

Versions of cryptiles prior to 4.1.2 are vulnerable to Insufficient Entropy. The randomDigits() method does not provide sufficient entropy and its generates digits that are not evenly distributed.

Recommendation

Upgrade to version 4.1.2. The package is deprecated and has been moved to @hapi/cryptiles and it is strongly recommended to use the maintained package.

Affected repositories (1)

#1005236: property-expr (CVE-2020-7707)

Severity: critical

The package property-expr before 2.0.3 are vulnerable to Prototype Pollution via the setter function.

Affected repositories (1)

#1002431: mixme

Severity: high

Impact

When copying properties from a source object to a target object, the target object can gain access to certain properties of the source object and modify their content.

Patches

The problem was patch with a more agressive discovery of secured properties to filter out.

Affected repositories (1)

#1002475: set-value (CVE-2021-23440)

Severity: high

This affects the package set-value before 4.0.1. A type confusion vulnerability can lead to a bypass of CVE-2019-10747 when the user-provided keys used in the path parameter are arrays.

Affected repositories (6)

#1002477: axios (CVE-2021-3749)

Severity: high

axios is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (4)

#1002487: immer (CVE-2021-3757)

Severity: high

immer is vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

Affected repositories (4)

#1002503: tar (CVE-2021-37713)

Severity: high

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to guarantee that any file whose location would be outside of the extraction target directory is not extracted. This is, in part, accomplished by sanitizing absolute paths of entries within the archive, skipping archive entries that contain .. path portions, and resolving the sanitized paths against the extraction target directory.

This logic was insufficient on Windows systems when extracting tar files that contained a path that was not an absolute path, but specified a drive letter different from the extraction target, such as C:some\path. If the drive letter does not match the extraction target, for example D:\extraction\dir, then the result of path.resolve(extractionDirectory, entryPath) would resolve against the current working directory on the C: drive, rather than the extraction target directory.

Additionally, a .. portion of the path could occur immediately after the drive letter, such as C:../foo, and was not properly sanitized by the logic that checked for .. within the normalized and split portions of the path.

This only affects users of node-tar on Windows systems.

Patches

4.4.18 || 5.0.10 || 6.1.9

Workarounds

There is no reasonable way to work around this issue without performing the same path normalization procedures that node-tar now does.

Users are encouraged to upgrade to the latest patched versions of node-tar, rather than attempt to sanitize paths themselves.

Fix

The fixed versions strip path roots from all paths prior to being resolved against the extraction target folder, even if such paths are not "absolute".

Additionally, a path starting with a drive letter and then two dots, like c:../, would bypass the check for .. path portions. This is checked properly in the patched versions.

Finally, a defense in depth check is added, such that if the entry.absolute is outside of the extraction taret, and we are not in preservePaths:true mode, a warning is raised on that entry, and it is skipped. Currently, it is believed that this check is redundant, but it did catch some oversights in development.

Affected repositories (7)

#1002506: tar (CVE-2021-37712)

Severity: high

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to guarantee that any file whose location would be modified by a symbolic link is not extracted. This is, in part, achieved by ensuring that extracted directories are not symlinks. Additionally, in order to prevent unnecessary stat calls to determine whether a given path is a directory, paths are cached when directories are created.

This logic was insufficient when extracting tar files that contained two directories and a symlink with names containing unicode values that normalized to the same value. Additionally, on Windows systems, long path portions would resolve to the same file system entities as their 8.3 "short path" counterparts. A specially crafted tar archive could thus include directories with two forms of the path that resolve to the same file system entity, followed by a symbolic link with a name in the first form, lastly followed by a file using the second form. It led to bypassing node-tar symlink checks on directories, essentially allowing an untrusted tar file to symlink into an arbitrary location and subsequently extracting arbitrary files into that location, thus allowing arbitrary file creation and overwrite.

The v3 branch of node-tar has been deprecated and did not receive patches for these issues. If you are still using a v3 release we recommend you update to a more recent version of node-tar. If this is not possible, a workaround is available below.

Patches

6.1.9 || 5.0.10 || 4.4.18

Workarounds

Users may work around this vulnerability without upgrading by creating a custom filter method which prevents the extraction of symbolic links.

```js const tar = require('tar')

tar.x({ file: 'archive.tgz', filter: (file, entry) => { if (entry.type === 'SymbolicLink') { return false } else { return true } } }) ```

Users are encouraged to upgrade to the latest patched versions, rather than attempt to sanitize tar input themselves.

Fix

The problem is addressed in the following ways, when comparing paths in the directory cache and path reservation systems:

  1. The String.normalize('NFKD') method is used to first normalize all unicode to its maximally compatible and multi-code-point form.
  2. All slashes are normalized to / on Windows systems (on posix systems, \ is a valid filename character, and thus left intact).
  3. When a symbolic link is encountered on Windows systems, the entire directory cache is cleared. Collisions related to use of 8.3 short names to replace directories with other (non-symlink) types of entries may make archives fail to extract properly, but will not result in arbitrary file writes.
Affected repositories (7)

#1002509: tar (CVE-2021-37701)

Severity: high

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to guarantee that any file whose location would be modified by a symbolic link is not extracted. This is, in part, achieved by ensuring that extracted directories are not symlinks. Additionally, in order to prevent unnecessary stat calls to determine whether a given path is a directory, paths are cached when directories are created.

This logic was insufficient when extracting tar files that contained both a directory and a symlink with the same name as the directory, where the symlink and directory names in the archive entry used backslashes as a path separator on posix systems. The cache checking logic used both \ and / characters as path separators, however \ is a valid filename character on posix systems.

By first creating a directory, and then replacing that directory with a symlink, it was thus possible to bypass node-tar symlink checks on directories, essentially allowing an untrusted tar file to symlink into an arbitrary location and subsequently extracting arbitrary files into that location, thus allowing arbitrary file creation and overwrite.

Additionally, a similar confusion could arise on case-insensitive filesystems. If a tar archive contained a directory at FOO, followed by a symbolic link named foo, then on case-insensitive file systems, the creation of the symbolic link would remove the directory from the filesystem, but not from the internal directory cache, as it would not be treated as a cache hit. A subsequent file entry within the FOO directory would then be placed in the target of the symbolic link, thinking that the directory had already been created.

These issues were addressed in releases 4.4.16, 5.0.8 and 6.1.7.

The v3 branch of node-tar has been deprecated and did not receive patches for these issues. If you are still using a v3 release we recommend you update to a more recent version of node-tar. If this is not possible, a workaround is available below.

Patches

4.4.16 || 5.0.8 || 6.1.7

Workarounds

Users may work around this vulnerability without upgrading by creating a custom filter method which prevents the extraction of symbolic links.

```js const tar = require('tar')

tar.x({ file: 'archive.tgz', filter: (file, entry) => { if (entry.type === 'SymbolicLink') { return false } else { return true } } }) ```

Users are encouraged to upgrade to the latest patched versions, rather than attempt to sanitize tar input themselves.

Fix

The problem is addressed in the following ways:

  1. All paths are normalized to use / as a path separator, replacing \ with / on Windows systems, and leaving \ intact in the path on posix systems. This is performed in depth, at every level of the program where paths are consumed.
  2. Directory cache pruning is performed case-insensitively. This may result in undue cache misses on case-sensitive file systems, but the performance impact is negligible.

Caveat

Note that this means that the entry objects exposed in various parts of tar's API will now always use / as a path separator, even on Windows systems. This is not expected to cause problems, as / is a valid path separator on Windows systems, but may result in issues if entry.path is compared against a path string coming from some other API such as fs.realpath() or path.resolve().

Users are encouraged to always normalize paths using a well-tested method such as path.resolve() before comparing paths to one another.

Affected repositories (7)

#1002522: ansi-html (CVE-2021-23424)

Severity: high

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.

Affected repositories (4)

#1002541: tar (CVE-2021-32804)

Severity: high

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to prevent extraction of absolute file paths by turning absolute paths into relative paths when the preservePaths flag is not set to true. This is achieved by stripping the absolute path root from any absolute file paths contained in a tar file. For example /home/user/.bashrc would turn into home/user/.bashrc.

This logic was insufficient when file paths contained repeated path roots such as ////home/user/.bashrc. node-tar would only strip a single path root from such paths. When given an absolute file path with repeating path roots, the resulting path (e.g. ///home/user/.bashrc) would still resolve to an absolute path, thus allowing arbitrary file creation and overwrite.

Patches

3.2.2 || 4.4.14 || 5.0.6 || 6.1.1

NOTE: an adjacent issue CVE-2021-32803 affects this release level. Please ensure you update to the latest patch levels that address CVE-2021-32803 as well if this adjacent issue affects your node-tar use case.

Workarounds

Users may work around this vulnerability without upgrading by creating a custom onentry method which sanitizes the entry.path or a filter method which removes entries with absolute paths.

```js const path = require('path') const tar = require('tar')

tar.x({ file: 'archive.tgz', // either add this function... onentry: (entry) => { if (path.isAbsolute(entry.path)) { entry.path = sanitizeAbsolutePathSomehow(entry.path) entry.absolute = path.resolve(entry.path) } },

// or this one filter: (file, entry) => { if (path.isAbsolute(entry.path)) { return false } else { return true } } }) ```

Users are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.

Affected repositories (6)

#1002542: tar (CVE-2021-32804)

Severity: high

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to prevent extraction of absolute file paths by turning absolute paths into relative paths when the preservePaths flag is not set to true. This is achieved by stripping the absolute path root from any absolute file paths contained in a tar file. For example /home/user/.bashrc would turn into home/user/.bashrc.

This logic was insufficient when file paths contained repeated path roots such as ////home/user/.bashrc. node-tar would only strip a single path root from such paths. When given an absolute file path with repeating path roots, the resulting path (e.g. ///home/user/.bashrc) would still resolve to an absolute path, thus allowing arbitrary file creation and overwrite.

Patches

3.2.2 || 4.4.14 || 5.0.6 || 6.1.1

NOTE: an adjacent issue CVE-2021-32803 affects this release level. Please ensure you update to the latest patch levels that address CVE-2021-32803 as well if this adjacent issue affects your node-tar use case.

Workarounds

Users may work around this vulnerability without upgrading by creating a custom onentry method which sanitizes the entry.path or a filter method which removes entries with absolute paths.

```js const path = require('path') const tar = require('tar')

tar.x({ file: 'archive.tgz', // either add this function... onentry: (entry) => { if (path.isAbsolute(entry.path)) { entry.path = sanitizeAbsolutePathSomehow(entry.path) entry.absolute = path.resolve(entry.path) } },

// or this one filter: (file, entry) => { if (path.isAbsolute(entry.path)) { return false } else { return true } } }) ```

Users are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.

Affected repositories (1)

#1002545: tar (CVE-2021-32803)

Severity: high

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to guarantee that any file whose location would be modified by a symbolic link is not extracted. This is, in part, achieved by ensuring that extracted directories are not symlinks. Additionally, in order to prevent unnecessary stat calls to determine whether a given path is a directory, paths are cached when directories are created.

This logic was insufficient when extracting tar files that contained both a directory and a symlink with the same name as the directory. This order of operations resulted in the directory being created and added to the node-tar directory cache. When a directory is present in the directory cache, subsequent calls to mkdir for that directory are skipped. However, this is also where node-tar checks for symlinks occur.

By first creating a directory, and then replacing that directory with a symlink, it was thus possible to bypass node-tar symlink checks on directories, essentially allowing an untrusted tar file to symlink into an arbitrary location and subsequently extracting arbitrary files into that location, thus allowing arbitrary file creation and overwrite.

This issue was addressed in releases 3.2.3, 4.4.15, 5.0.7 and 6.1.2.

Patches

3.2.3 || 4.4.15 || 5.0.7 || 6.1.2

Workarounds

Users may work around this vulnerability without upgrading by creating a custom filter method which prevents the extraction of symbolic links.

```js const tar = require('tar')

tar.x({ file: 'archive.tgz', filter: (file, entry) => { if (entry.type === 'SymbolicLink') { return false } else { return true } } }) ```

Users are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.

Affected repositories (6)

#1002546: tar (CVE-2021-32803)

Severity: high

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to guarantee that any file whose location would be modified by a symbolic link is not extracted. This is, in part, achieved by ensuring that extracted directories are not symlinks. Additionally, in order to prevent unnecessary stat calls to determine whether a given path is a directory, paths are cached when directories are created.

This logic was insufficient when extracting tar files that contained both a directory and a symlink with the same name as the directory. This order of operations resulted in the directory being created and added to the node-tar directory cache. When a directory is present in the directory cache, subsequent calls to mkdir for that directory are skipped. However, this is also where node-tar checks for symlinks occur.

By first creating a directory, and then replacing that directory with a symlink, it was thus possible to bypass node-tar symlink checks on directories, essentially allowing an untrusted tar file to symlink into an arbitrary location and subsequently extracting arbitrary files into that location, thus allowing arbitrary file creation and overwrite.

This issue was addressed in releases 3.2.3, 4.4.15, 5.0.7 and 6.1.2.

Patches

3.2.3 || 4.4.15 || 5.0.7 || 6.1.2

Workarounds

Users may work around this vulnerability without upgrading by creating a custom filter method which prevents the extraction of symbolic links.

```js const tar = require('tar')

tar.x({ file: 'archive.tgz', filter: (file, entry) => { if (entry.type === 'SymbolicLink') { return false } else { return true } } }) ```

Users are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.

Affected repositories (1)

#1002576: socket.io-parser (CVE-2020-36049)

Severity: high

The socket.io-parser npm package before versions 3.3.2 and 3.4.1 allows attackers to cause a denial of service (memory consumption) via a large packet because a concatenation approach is used.

Affected repositories (1)

#1002580: prismjs (CVE-2021-32723)

Severity: high

Some languages before 1.24.0 are vulnerable to Regular Expression Denial of Service (ReDoS).

Impact

When Prism is used to highlight untrusted (user-given) text, an attacker can craft a string that will take a very very long time to highlight. Do not use the following languages to highlight untrusted text.

Other languages are not affected and can be used to highlight untrusted text.

Patches

This problem has been fixed in Prism v1.24.

References

Affected repositories (5)

#1002624: trim-newlines (CVE-2021-33623)

Severity: high

The trim-newlines package before 3.0.1 and 4.x before 4.0.1 for Node.js has an issue related to regular expression denial-of-service (ReDoS) for the .end() method.

Affected repositories (8)

#1002627: glob-parent (CVE-2020-28469)

Severity: high

This affects the package glob-parent before 5.1.2. The enclosure regex used to check for strings ending in enclosure containing path separator.

Affected repositories (7)

#1002742: xmlhttprequest-ssl (CVE-2020-28502)

Severity: high

This affects the package xmlhttprequest before 1.7.0; all versions of package xmlhttprequest-ssl. Provided requests are sent synchronously (async=False on xhr.open), malicious user input flowing into xhr.send could result in arbitrary code being injected and run.

Affected repositories (1)

#1002748: ua-parser-js (CVE-2020-7733)

Severity: high

The package ua-parser-js before 0.7.22 are vulnerable to Regular Expression Denial of Service (ReDoS) via the regex for Redmi Phones and Mi Pad Tablets UA.

Affected repositories (3)

#1002807: ssri (CVE-2021-27290)

Severity: high

npm ssri 5.2.2-6.0.1 and 7.0.0-8.0.0, processes SRIs using a regular expression which is vulnerable to a denial of service. Malicious SRIs could take an extremely long time to process, leading to denial of service. This issue only affects consumers using the strict option.

Affected repositories (1)

#1002847: lodash (CVE-2021-23337)

Severity: high

lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function.

Affected repositories (1)

#1002849: underscore (CVE-2021-23358)

Severity: high

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.

Affected repositories (51)

#1002886: url-parse (CVE-2021-27515)

Severity: high

url-parse before 1.5.0 mishandles certain uses of backslash such as http:\/ and interprets the URI as a relative path.

Affected repositories (1)

#1002888: ua-parser-js (CVE-2021-27292)

Severity: high

ua-parser-js >= 0.7.14, fixed in 0.7.24, uses a regular expression which is vulnerable to denial of service. If an attacker sends a malicious User-Agent header, ua-parser-js will get stuck processing it for an extended period of time.

Affected repositories (3)

#1002899: merge (CVE-2020-28499)

Severity: high

All versions of package merge <2.1.1 are vulnerable to Prototype Pollution via _recursiveMerge .

Affected repositories (1)

#1002911: is-svg (CVE-2021-28092)

Severity: high

The is-svg package 2.1.0 through 4.2.1 for Node.js uses a regular expression that is vulnerable to Regular Expression Denial of Service (ReDoS). If an attacker provides a malicious string, is-svg will get stuck processing the input for a very long time.

Affected repositories (2)

#1002915: y18n (CVE-2020-7774)

Severity: high

Overview

The npm package y18n before versions 3.2.2, 4.0.1, and 5.0.5 is vulnerable to Prototype Pollution.

POC

``` const y18n = require('y18n')();

y18n.setLocale('proto'); y18n.updateLocale({polluted: true});

console.log(polluted); // true ```

Recommendation

Upgrade to version 3.2.2, 4.0.1, 5.0.5 or later.

Affected repositories (1)

#1002944: prismjs (CVE-2021-23341)

Severity: high

The package prismjs before 1.23.0 are vulnerable to Regular Expression Denial of Service (ReDoS) via the prism-asciidoc, prism-rest, prism-tap and prism-eiffel components.

Affected repositories (5)

#1002973: immer (CVE-2020-28477)

Severity: high

Overview

Affected versions of immer are vulnerable to Prototype Pollution.

Proof of exploit

const {applyPatches, enablePatches} = require("immer"); enablePatches(); let obj = {}; console.log("Before : " + obj.polluted); applyPatches({}, [ { op: 'add', path: [ "__proto__", "polluted" ], value: "yes" } ]); // applyPatches({}, [ { op: 'replace', path: [ "__proto__", "polluted" ], value: "yes" } ]); console.log("After : " + obj.polluted);

Remediation

Version 8.0.1 contains a fix for this vulnerability, updating is recommended.

Affected repositories (4)

#1002990: axios (CVE-2020-28168)

Severity: high

Axios NPM package 0.21.0 contains a Server-Side Request Forgery (SSRF) vulnerability where an attacker is able to bypass a proxy by providing a URL that responds with a redirect to a restricted host or IP address.

Affected repositories (1)

#1003007: ini (CVE-2020-7788)

Severity: high

Overview

The ini npm package before version 1.3.6 has a Prototype Pollution vulnerability.

If an attacker submits a malicious INI file to an application that parses it with ini.parse, they will pollute the prototype on the application. This can be exploited further depending on the context.

Patches

This has been patched in 1.3.6

Steps to reproduce

payload.ini [__proto__] polluted = "polluted"

poc.js: ``` var fs = require('fs') var ini = require('ini')

var parsed = ini.parse(fs.readFileSync('./payload.ini', 'utf-8')) console.log(parsed) console.log(parsed.proto) console.log(polluted) ```

```

node poc.js {} { polluted: 'polluted' } { polluted: 'polluted' } polluted ```

Affected repositories (6)

#1003051: node-forge (CVE-2020-7720)

Severity: high

The package node-forge before 0.10.0 is vulnerable to Prototype Pollution via the util.setPath function. Note: Version 0.10.0 is a breaking change removing the vulnerable functions.

Affected repositories (1)

#1003058: bl (CVE-2020-8244)

Severity: high

A buffer over-read vulnerability exists in bl <4.0.3, <3.0.1, <2.2.1, and <1.2.3 which could allow an attacker to supply user input (even typed) that if it ends up in consume() argument and can become negative, the BufferList state can be corrupted, tricking it into exposing uninitialized memory via regular .slice() calls.

Affected repositories (3)

#1003061: bl (CVE-2020-8244)

Severity: high

A buffer over-read vulnerability exists in bl <4.0.3, <3.0.1, <2.2.1, and <1.2.3 which could allow an attacker to supply user input (even typed) that if it ends up in consume() argument and can become negative, the BufferList state can be corrupted, tricking it into exposing uninitialized memory via regular .slice() calls.

Affected repositories (1)

#1003325: markdown-to-jsx

Severity: high

Versions of markdown-to-jsx prior to 6.11.4 are vulnerable to Cross-Site Scripting. Due to insufficient input sanitization the package may render output containing malicious JavaScript. This vulnerability can be exploited through input of links containing data or VBScript URIs and a base64-encoded payload.

Recommendation

Upgrade to version 6.11.4 or later.

Affected repositories (1)

#1003633: static-eval

Severity: high

Versions of static-evalprior to 2.0.2 pass untrusted user input directly to the global function constructor, resulting in an arbitrary code execution vulnerability when user input is parsed via the package.

Proof of concept

``` var evaluate = require('static-eval'); var parse = require('esprima').parse;

var src = process.argv[2]; var payload = '(function({x}){return x.constructor})({x:"".sub})("console.log(process.env)")()' var ast = parse(payload).body[0].expression; console.log(evaluate(ast, {x:1})); ```

Recommendation

Upgrade to version 2.0.2 or later.

Affected repositories (1)

#1004041: serialize-javascript (CVE-2020-7660)

Severity: high

serialize-javascript prior to 3.1.0 allows remote attackers to inject arbitrary code via the function "deleteFunctions" within "index.js".

An object such as {"foo": /1"/, "bar": "a\"@__R-<UID>-0__@"} was serialized as {"foo": /1"/, "bar": "a\/1"/}, which allows an attacker to escape the bar key. This requires the attacker to control the values of both foo and bar and guess the value of <UID>. The UID has a keyspace of approximately 4 billion making it a realistic network attack.

Affected repositories (2)

#1004043: prismjs (CVE-2020-15138)

Severity: high

Impact

The easing preview of the Previewers plugin has an XSS vulnerability that allows attackers to execute arbitrary code in Safari and Internet Explorer.

This impacts all Safari and Internet Explorer users of Prism >=v1.1.0 that use the Previewers plugin (>=v1.10.0) or the Previewer: Easing plugin (v1.1.0 to v1.9.0).

Patches

This problem is patched in v1.21.0.

Workarounds

To workaround the issue without upgrading, disable the easing preview on all impacted code blocks. You need Prism v1.10.0 or newer to apply this workaround.

References

The vulnerability was introduced by this commit on Sep 29, 2015 and fixed by Masato Kinugawa (#2506).

For more information

If you have any questions or comments about this advisory, please open an issue.

Affected repositories (5)

#1004052: elliptic (CVE-2020-13822)

Severity: high

The Elliptic package before version 6.5.3 for Node.js allows ECDSA signature malleability via variations in encoding, leading '\0' bytes, or integer overflows. This could conceivably have a security-relevant impact if an application relied on a single canonical signature.

Affected repositories (1)

#1004079: kind-of (CVE-2019-20149)

Severity: high

Versions of kind-of 6.x prior to 6.0.3 are vulnerable to a Validation Bypass. A maliciously crafted object can alter the result of the type check, allowing attackers to bypass the type checking validation.

Recommendation

Upgrade to versions 6.0.3 or later.

Affected repositories (1)

#1004117: websocket-extensions (CVE-2020-7662)

Severity: high

Impact

The ReDoS flaw allows an attacker to exhaust the server's capacity to process incoming requests by sending a WebSocket handshake request containing a header of the following form:

Sec-WebSocket-Extensions: a; b="\c\c\c\c\c\c\c\c\c\c ...

That is, a header containing an unclosed string parameter value whose content is a repeating two-byte sequence of a backslash and some other character. The parser takes exponential time to reject this header as invalid, and this will block the processing of any other work on the same thread. Thus if you are running a single-threaded server, such a request can render your service completely unavailable.

Patches

Users should upgrade to version 0.1.4.

Workarounds

There are no known work-arounds other than disabling any public-facing WebSocket functionality you are operating.

References

Affected repositories (1)

#1004139: acorn

Severity: high

Affected versions of acorn are vulnerable to Regular Expression Denial of Service. A regex in the form of /[x-\ud800]/u causes the parser to enter an infinite loop. The string is not valid UTF16 which usually results in it being sanitized before reaching the parser. If an application processes untrusted input and passes it directly to acorn, attackers may leverage the vulnerability leading to Denial of Service.

Affected repositories (1)

#1004151: acorn

Severity: high

Affected versions of acorn are vulnerable to Regular Expression Denial of Service. A regex in the form of /[x-\ud800]/u causes the parser to enter an infinite loop. The string is not valid UTF16 which usually results in it being sanitized before reaching the parser. If an application processes untrusted input and passes it directly to acorn, attackers may leverage the vulnerability leading to Denial of Service.

Affected repositories (1)

#1004302: diff

Severity: high

A vulnerability was found in diff before v3.5.0, the affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) attacks.

Affected repositories (2)

#1004865: graphiql (CVE-2021-41248)

Severity: high

This is a security advisory for an XSS vulnerability in graphiql.

A similar vulnerability affects graphql-playground, a fork of graphiql. There is a corresponding graphql-playground advisory and Apollo Server advisory.

1. Impact

All versions of graphiql older than graphiql@1.4.7 are vulnerable to compromised HTTP schema introspection responses or schema prop values with malicious GraphQL type names, exposing a dynamic XSS attack surface that can allow code injection on operation autocomplete.

In order for the attack to take place, the user must load a vulnerable schema in graphiql. There are a number of ways that can occur.

By default, the schema URL is not attacker-controllable in graphiql or in its suggested implementations or examples, leaving only very complex attack vectors.

If a custom implementation of graphiql's fetcher allows the schema URL to be set dynamically, such as a URL query parameter like ?endpoint= in graphql-playground, or a database provided value, then this custom graphiql implementation is vulnerable to phishing attacks, and thus much more readily available, low or no privelege level xss attacks. The URLs could look like any generic looking graphql schema URL.

Because this exposes an XSS attack surface, it would be possible for a threat actor to exfiltrate user credentials, data, etc. using arbitrary malicious scripts, without it being known to the user.

2. Scope

This advisory describes the impact on the graphiql package. The vulnerability also affects other projects forked from graphiql such as graphql-playground and the graphql-playground fork distributed by Apollo Server. The impact is more severe in the graphql-playground implementations; see the graphql-playground advisory and Apollo Server advisory for details.

This vulnerability does not impact codemirror-graphql, monaco-graphql or other dependents, as it exists in onHasCompletion.ts in graphiql. It does impact all forks of graphiql, and every released version of graphiql.

It should be noted that desktop clients such as Altair, Insomnia, Postwoman, do not appear to be impacted by this.

3. Patches

graphiql@1.4.7 addresses this issue via defense in depth.

3.1 CDN bundle implementations may be automatically patched

Note that if your implementation is depending on a CDN version of graphiql, and is pointed to the latest tag (usually the default for most cdns if no version is specified) then this issue is already mitigated, in case you were vulnerable to it before.

4. Workarounds for Older Versions

If you cannot use graphiql@1.4.7 or later

5. How to Re-create the Exploit

You can see an example on codesandbox. These are both fixed to the last graphiql release 1.4.6 which is the last vulnerable release; however it would work with any previous release of graphiql.

Both of these examples are meant to demonstrate the phishing attack surface, so they are customized to accept a url parameter. To demonstrate the phishing attack, add ?url=https://graphql-xss-schema.netlify.app/graphql to the in-codesandbox browser.

Erase the contents of the given query and type {u. You will see an alert window open, showing that attacker-controlled code was executed.

Note that when React is in development mode, a validation exception is thrown visibly; however that exception is usually buried in the browser console in a production build of graphiql. This validation exception comes from getDiagnostics, which invokes graphql validate() which in turn will assertValidSchema(), as apollo-server-core does on executing each operation. This validation does not prevent the exploit from being successful.

Note that something like the url parameter is not required for the attack to happen if graphiql's fetcher is configured in a different way to communicate with a compromised GraphQL server.

6. Credit

This vulnerability was discovered by @Ry0taK, thank you! :1st_place_medal:

Others who contributed:

7. References

The vulnerability has always been present

In the first commit

And later moved to onHasCompletion.js in 2016 (now .ts after the typescript migration)

8. For more information

If you have any questions or comments about this advisory:

Affected repositories (1)

#1005154: glob-parent (CVE-2020-28469)

Severity: high

This affects the package glob-parent before 5.1.2. The enclosure regex used to check for strings ending in enclosure containing path separator.

Affected repositories (1)

#1005367: underscore (CVE-2021-23358)

Severity: high

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.

Affected repositories (473)

#1005415: merge (CVE-2020-28499)

Severity: high

All versions of package merge <2.1.1 are vulnerable to Prototype Pollution via _recursiveMerge .

Affected repositories (1)

#1006754: trim-newlines (CVE-2021-33623)

Severity: high

The trim-newlines package before 3.0.1 and 4.x before 4.0.1 for Node.js has an issue related to regular expression denial-of-service (ReDoS) for the .end() method.

Affected repositories (1)

#1002401: ansi-regex (CVE-2021-3807)

Severity: moderate

ansi-regex is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (267)

#1002402: ws (CVE-2021-32640)

Severity: moderate

Impact

A specially crafted value of the Sec-Websocket-Protocol header can be used to significantly slow down a ws server.

Proof of concept

```js for (const length of [1000, 2000, 4000, 8000, 16000, 32000]) { const value = 'b' + ' '.repeat(length) + 'x'; const start = process.hrtime.bigint();

value.trim().split(/ , /);

const end = process.hrtime.bigint();

console.log('length = %d, time = %f ns', length, end - start); } ```

Patches

The vulnerability was fixed in ws@7.4.6 (https://github.com/websockets/ws/commit/00c425ec77993773d823f018f64a5c44e17023ff) and backported to ws@6.2.2 (https://github.com/websockets/ws/commit/78c676d2a1acefbc05292e9f7ea0a9457704bf1b) and ws@5.2.3 (https://github.com/websockets/ws/commit/76d47c1479002022a3e4357b3c9f0e23a68d4cd2).

Workarounds

In vulnerable versions of ws, the issue can be mitigated by reducing the maximum allowed length of the request headers using the --max-http-header-size=size and/or the maxHeaderSize options.

Credits

The vulnerability was responsibly disclosed along with a fix in private by Robert McLaughlin from University of California, Santa Barbara.

Affected repositories (1)

#1002422: prismjs (CVE-2021-3801)

Severity: moderate

The prismjs package is vulnerable to ReDoS (regular expression denial of service). An attacker that is able to provide a crafted HTML comment as input may cause an application to consume an excessive amount of CPU.

Affected repositories (5)

#1002423: nth-check (CVE-2021-3803)

Severity: moderate

nth-check is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (10)

#1002465: semver-regex (CVE-2021-3795)

Severity: moderate

npm semver-regex is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (2)

#1002466: tmpl (CVE-2021-3777)

Severity: moderate

nodejs-tmpl is vulnerable to Inefficient Regular Expression Complexity which may lead to resource exhaustion.

Affected repositories (4)

#1002531: xmldom (CVE-2021-32796)

Severity: moderate

Impact

xmldom versions 0.6.0 and older do not correctly escape special characters when serializing elements removed from their ancestor. This may lead to unexpected syntactic changes during XML processing in some downstream applications.

Patches

Update to one of the fixed versions of @xmldom/xmldom (^0.5.1 || ^0.6.1 || >=0.7.0). :exclamation: Users of xmldom should switch to @xmldom/xmldom to not be affected by this vulnerability.

See issue #271 for the status of publishing xmldom to npm or join #270 for Q&A/discussion until it's resolved.

Workarounds

Downstream applications can validate the input and reject the maliciously crafted documents.

References

Similar to this one reported on the Go standard library:

For more information

If you have any questions or comments about this advisory:

Affected repositories (3)

#1002536: path-parse (CVE-2021-23343)

Severity: moderate

Affected versions of npm package path-parse are vulnerable to Regular Expression Denial of Service (ReDoS) via splitDeviceRe, splitTailRe, and splitPathRe regular expressions. ReDoS exhibits polynomial worst-case time complexity.

Affected repositories (2)

#1002549: url-parse (CVE-2021-3664)

Severity: moderate

Overview

Affected versions of npm url-parse are vulnerable to URL Redirection to Untrusted Site.

Impact

Depending on library usage and attacker intent, impacts may include allow/block list bypasses, SSRF attacks, open redirects, or other undesired behavior.

Affected repositories (3)

#1002553: video.js (CVE-2021-23414)

Severity: moderate

This affects the package video.js before 7.14.3. The src attribute of track tag allows to bypass HTML escaping and execute arbitrary code.

Affected repositories (1)

#1002581: color-string (CVE-2021-29060)

Severity: moderate

In the npm package color-string, there is a ReDos (Regular Expression Denial of Service) vulnerability regarding an exponential time complexity for linearly increasing input lengths for hwb() color strings.

Strings reaching more than 5000 characters would see several milliseconds of processing time; strings reaching more than 50,000 characters began seeing 1500ms (1.5s) of processing time.

The cause was due to a the regular expression that parses hwb() strings - specifically, the hue value - where the integer portion of the hue value used a 0-or-more quantifier shortly thereafter followed by a 1-or-more quantifier.

This caused excessive backtracking and a cartesian scan, resulting in exponential time complexity given a linear increase in input length.

Affected repositories (1)

#1002594: postcss (CVE-2021-23368)

Severity: moderate

The npm package postcss from 7.0.0 and before versions 7.0.36 and 8.2.10 is vulnerable to Regular Expression Denial of Service (ReDoS) during source map parsing.

Affected repositories (3)

#1002615: ws (CVE-2021-32640)

Severity: moderate

Impact

A specially crafted value of the Sec-Websocket-Protocol header can be used to significantly slow down a ws server.

Proof of concept

```js for (const length of [1000, 2000, 4000, 8000, 16000, 32000]) { const value = 'b' + ' '.repeat(length) + 'x'; const start = process.hrtime.bigint();

value.trim().split(/ , /);

const end = process.hrtime.bigint();

console.log('length = %d, time = %f ns', length, end - start); } ```

Patches

The vulnerability was fixed in ws@7.4.6 (https://github.com/websockets/ws/commit/00c425ec77993773d823f018f64a5c44e17023ff) and backported to ws@6.2.2 (https://github.com/websockets/ws/commit/78c676d2a1acefbc05292e9f7ea0a9457704bf1b) and ws@5.2.3 (https://github.com/websockets/ws/commit/76d47c1479002022a3e4357b3c9f0e23a68d4cd2).

Workarounds

In vulnerable versions of ws, the issue can be mitigated by reducing the maximum allowed length of the request headers using the --max-http-header-size=size and/or the maxHeaderSize options.

Credits

The vulnerability was responsibly disclosed along with a fix in private by Robert McLaughlin from University of California, Santa Barbara.

Affected repositories (2)

#1002655: browserslist (CVE-2021-23364)

Severity: moderate

The package browserslist from 4.0.0 and before 4.16.5 are vulnerable to Regular Expression Denial of Service (ReDoS) during parsing of queries.

Affected repositories (5)

#1002922: msgpack5 (CVE-2021-21368)

Severity: moderate

Impact

The issue is as follows: when msgpack5 decodes a map containing a key "__proto__", it assigns the decoded value to __proto__. As you are no doubt aware, Object.prototype.__proto__ is an accessor property for the receiver's prototype. If the value corresponding to the key __proto__ decodes to an object or null, msgpack5 sets the decoded object's prototype to that value.

An attacker who can submit crafted MessagePack data to a service can use this to produce values that appear to be of other types; may have unexpected prototype properties and methods (for example length, numeric properties, and push et al if __proto__'s value decodes to an Array); and/or may throw unexpected exceptions when used (for example if the __proto__ value decodes to a Map or Date). Other unexpected behavior might be produced for other types.

There is no effect on the global prototype.

An example:

```js const msgpack5 = require('msgpack5')();

const payload = {}; Object.defineProperty(payload, 'proto', { value: new Map().set(1, 2), enumerable: true });

const encoded = msgpack5.encode(payload); console.log(encoded); //

const decoded = msgpack5.decode(encoded);

// decoded's prototype has been overwritten console.log(Object.getPrototypeOf(decoded)); // Map(1) { 1 => 2 } console.log(decoded.get); // [Function: get]

// decoded appears to most common typechecks to be a Map console.log(decoded instanceof Map); // true console.log(decoded.toString()); // [object Map] console.log(Object.prototype.toString.call(decoded)); // [object Map] console.log(decoded.constructor.name); // Map console.log(Object.getPrototypeOf(decoded).constructor.name); // Map

// decoded is not, however, a Map console.log(Object.getPrototypeOf(decoded) === Map.prototype); // false

// using decoded as though it were a Map throws try { decoded.get(1); } catch (error) { console.log(error); // TypeError: Method Map.prototype.get called // on incompatible receiver # } try { decoded.size; } catch (error) { console.log(error); // TypeError: Method get Map.prototype.size // called on incompatible receiver # }

// re-encoding the decoded value throws try { msgpack5.encode(decoded); } catch (error) { console.log(error); // TypeError: Method Map.prototype.entries // called on incompatible receiver # } ```

This "prototype poisoning" is sort of a very limited inversion of a prototype pollution attack. Only the decoded value's prototype is affected, and it can only be set to msgpack5 values (though if the victim makes use of custom codecs, anything could be a msgpack5 value). We have not found a way to escalate this to true prototype pollution (absent other bugs in the consumer's code).

Patches

Versions v5.2.1, v4.5.1, v3.6.1 include the fix.

Workarounds

Always validate incoming data after parsing before doing any processing.

For more information

If you have any questions or comments about this advisory: * Open an issue in example link to repo * Email us at example email address

Affected repositories (1)

#1002925: react-dev-utils (CVE-2021-24033)

Severity: moderate

react-dev-utils prior to v11.0.4 exposes a function, getProcessForPort, where an input argument is concatenated into a command string to be executed. This function is typically used from react-scripts (in Create React App projects), where the usage is safe. Only when this function is manually invoked with user-provided values (ie: by custom code) is there the potential for command injection. If you're consuming it from react-scripts then this issue does not affect you.

Affected repositories (4)

#1002927: elliptic (CVE-2020-28498)

Severity: moderate

The npm package elliptic before version 6.5.4 are vulnerable to Cryptographic Issues via the secp256k1 implementation in elliptic/ec/key.js. There is no check to confirm that the public key point passed into the derive function actually exists on the secp256k1 curve. This results in the potential for the private key used in this implementation to be revealed after a number of ECDH operations are performed.

Affected repositories (1)

#1002974: socket.io (CVE-2020-28481)

Severity: moderate

The package socket.io before 2.4.0 are vulnerable to Insecure Defaults due to CORS Misconfiguration. All domains are whitelisted by default.

Affected repositories (1)

#1002996: node-notifier (CVE-2020-7789)

Severity: moderate

This affects the package node-notifier before 8.0.1. It allows an attacker to run arbitrary commands on Linux machines due to the options params not being sanitised when being passed an array.

Affected repositories (1)

#1003013: highlight.js

Severity: moderate

Impact: Potential ReDOS vulnerabilities (exponential and polynomial RegEx backtracking)

oswasp:

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.

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.

Patches

Workarounds / Mitigations

References

For more information

If you have any questions or comments about this advisory: * Open an issue: https://github.com/highlightjs/highlight.js/issues * Email us at security@highlightjs.com

Affected repositories (4)

#1003019: yargs-parser (CVE-2020-7608)

Severity: moderate

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.

Recommendation

Upgrade to versions 13.1.2, 15.0.1, 18.1.1 or later.

Affected repositories (1)

#1003079: yargs-parser (CVE-2020-7608)

Severity: moderate

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.

Recommendation

Upgrade to versions 13.1.2, 15.0.1, 18.1.1 or later.

Affected repositories (1)

#1004058: jpeg-js (CVE-2020-8175)

Severity: moderate

Uncontrolled resource consumption in jpeg-js before 0.4.0 may allow attacker to launch denial of service attacks using specially a crafted JPEG image.

Affected repositories (1)

#1004140: jquery (CVE-2020-11022)

Severity: moderate

Impact

Passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code.

Patches

This problem is patched in jQuery 3.5.0.

Workarounds

To workaround the issue without upgrading, adding the following to your code:

js jQuery.htmlPrefilter = function( html ) { return html; };

You need to use at least jQuery 1.12/2.2 or newer to be able to apply this workaround.

References

https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/ https://jquery.com/upgrade-guide/3.5/

For more information

If you have any questions or comments about this advisory, search for a relevant issue in the jQuery repo. If you don't find an answer, open a new issue.

Affected repositories (2)

#1004141: jquery (CVE-2020-11023)

Severity: moderate

Impact

Passing HTML containing <option> elements from untrusted sources - even after sanitizing them - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code.

Patches

This problem is patched in jQuery 3.5.0.

Workarounds

To workaround this issue without upgrading, use DOMPurify with its SAFE_FOR_JQUERY option to sanitize the HTML string before passing it to a jQuery method.

References

https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/

For more information

If you have any questions or comments about this advisory, search for a relevant issue in the jQuery repo. If you don't find an answer, open a new issue.

Affected repositories (2)

#1004152: minimist (CVE-2020-7598)

Severity: moderate

Affected versions of minimist 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 --__proto__.y=Polluted adds a y property with value Polluted to all objects. The argument --__proto__=Polluted raises and uncaught error and crashes the application.
This is exploitable if attackers have control over the arguments being passed to minimist.

Recommendation

Upgrade to versions 0.2.1, 1.2.3 or later.

Affected repositories (4)

#1004153: minimist (CVE-2020-7598)

Severity: moderate

Affected versions of minimist 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 --__proto__.y=Polluted adds a y property with value Polluted to all objects. The argument --__proto__=Polluted raises and uncaught error and crashes the application.
This is exploitable if attackers have control over the arguments being passed to minimist.

Recommendation

Upgrade to versions 0.2.1, 1.2.3 or later.

Affected repositories (7)

#1004205: serialize-javascript (CVE-2019-16769)

Severity: moderate

Versions of serialize-javascript prior to 2.1.1 are vulnerable to Cross-Site Scripting (XSS). The package fails to sanitize serialized regular expressions. This vulnerability does not affect Node.js applications.

Recommendation

Upgrade to version 2.1.1 or later.

Affected repositories (1)

#1004380: jquery (CVE-2019-11358)

Severity: moderate

jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable proto property, it could extend the native Object.prototype.

Affected repositories (1)

#1004608: static-eval (CVE-2017-16226)

Severity: moderate

Affected versions of static-eval pass untrusted user input directly to the global function constructor, resulting in an arbitrary code execution vulnerability when user input is parsed via the package.

Proof of concept

var evaluate = require('static-eval'); var parse = require('esprima').parse; var src = '(function(){console.log(process.pid)})()'; var ast = parse(src).body[0].expression; var res = evaluate(ast, {}); // Will print the process id

Recommendation

Update to version 2.0.0 or later.

Affected repositories (1)

#1004784: validator (CVE-2021-3765)

Severity: moderate

validator.js prior to 13.7.0 is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (2)

#1004876: validator (CVE-2021-3765)

Severity: moderate

validator.js prior to 13.7.0 is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (2)

#1004946: ansi-regex (CVE-2021-3807)

Severity: moderate

ansi-regex is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (23)

#1004967: nth-check (CVE-2021-3803)

Severity: moderate

nth-check is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (9)

#1005067: xmldom (CVE-2021-32796)

Severity: moderate

Impact

xmldom versions 0.6.0 and older do not correctly escape special characters when serializing elements removed from their ancestor. This may lead to unexpected syntactic changes during XML processing in some downstream applications.

Patches

Update to one of the fixed versions of @xmldom/xmldom (^0.5.1 || ^0.6.1 || >=0.7.0). :exclamation: Users of xmldom should switch to @xmldom/xmldom to not be affected by this vulnerability.

See issue #271 for the status of publishing xmldom to npm or join #270 for Q&A/discussion until it's resolved.

Workarounds

Downstream applications can validate the input and reject the maliciously crafted documents.

References

Similar to this one reported on the Go standard library:

For more information

If you have any questions or comments about this advisory:

Affected repositories (1)

#1005293: codemirror (CVE-2020-7760)

Severity: moderate

This affects the package codemirror before 5.58.2; the package org.apache.marmotta.webjars:codemirror before 5.58.2. The vulnerable regular expression is located in https://github.com/codemirror/CodeMirror/blob/cdb228ac736369c685865b122b736cd0d397836c/mode/javascript/javascript.jsL129. The ReDOS vulnerability of the regex is mainly due to the sub-pattern (s|/.?/)

Affected repositories (1)

#1006180: minimist (CVE-2020-7598)

Severity: moderate

Affected versions of minimist 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 --__proto__.y=Polluted adds a y property with value Polluted to all objects. The argument --__proto__=Polluted raises and uncaught error and crashes the application.
This is exploitable if attackers have control over the arguments being passed to minimist.

Recommendation

Upgrade to versions 0.2.1, 1.2.3 or later.

Affected repositories (1)

#1006724: json-schema (CVE-2021-3918)

Severity: moderate

json-schema is vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

Affected repositories (2)

#1006725: validator

Severity: moderate

Impact

Versions of validator prior to 13.7.0 are affected by an inefficient Regular Expression complexity when using the rtrim and trim sanitizers.

Patches

The problem has been patched in validator 13.7.0

Affected repositories (2)

#1006846: postcss (CVE-2021-23382)

Severity: moderate

The package postcss before 8.2.13 are vulnerable to Regular Expression Denial of Service (ReDoS) via getAnnotationURL() and loadAnnotation() in lib/previous-map.js. The vulnerable regexes are caused mainly by the sub-pattern \/*\s sourceMappingURL=(.).

Affected repositories (54)

#1006864: markdown-it (CVE-2022-21670)

Severity: moderate

Impact

Special patterns with length > 50K chars can slow down parser significantly.

```js const md = require('markdown-it')();

md.render(x ${' '.repeat(150000)} x \nx); ```

Patches

Upgrade to v12.3.2+

Workarounds

No.

References

Fix + test sample: https://github.com/markdown-it/markdown-it/commit/ffc49ab46b5b751cd2be0aabb146f2ef84986101

Affected repositories (1)

#1006882: shelljs

Severity: moderate

Impact

Output from the synchronous version of shell.exec() may be visible to other users on the same system. You may be affected if you execute shell.exec() in multi-user Mac, Linux, or WSL environments, or if you execute shell.exec() as the root user.

Other shelljs functions (including the asynchronous version of shell.exec()) are not impacted.

Patches

Patched in shelljs 0.8.5

Workarounds

Recommended action is to upgrade to 0.8.5.

References

https://huntr.dev/bounties/50996581-c08e-4eed-a90e-c0bac082679c/

For more information

If you have any questions or comments about this advisory: * Ask at https://github.com/shelljs/shelljs/issues/1058 * Open an issue at https://github.com/shelljs/shelljs/issues/new

Affected repositories (105)

#1002923: xmldom (CVE-2021-21366)

Severity: low

Impact

xmldom versions 0.4.0 and older do not correctly preserve system identifiers, FPIs or namespaces when repeatedly parsing and serializing maliciously crafted documents.

This may lead to unexpected syntactic changes during XML processing in some downstream applications.

Patches

Update to 0.5.0 (once it is released)

Workarounds

Downstream applications can validate the input and reject the maliciously crafted documents.

References

Similar to this one reported on the Go standard library:

For more information

If you have any questions or comments about this advisory:

Affected repositories (3)

#1003016: highlight.js (CVE-2020-26237)

Severity: low

Impact

Affected versions of this package are vulnerable to Prototype Pollution. A malicious HTML code block can be crafted that will result in prototype pollution of the base object's prototype during highlighting. If you allow users to insert custom HTML code blocks into your page/app via parsing Markdown code blocks (or similar) and do not filter the language names the user can provide you may be vulnerable.

The pollution should just be harmless data but this can cause problems for applications not expecting these properties to exist and can result in strange behavior or application crashes, i.e. a potential DOS vector.

If your website or application does not render user provided data it should be unaffected.

Patches

Versions 9.18.2 and 10.1.2 and newer include fixes for this vulnerability. If you are using version 7 or 8 you are encouraged to upgrade to a newer release.

Workarounds

Patch your library

Manually patch your library to create null objects for both languages and aliases:

js const HLJS = function(hljs) { // ... var languages = Object.create(null); var aliases = Object.create(null);

Filter out bad data from end users

Filter the language names that users are allowed to inject into your HTML to guarantee they are valid.

References

For more information

If you have any questions or comments about this advisory:

Affected repositories (4)

#1003055: node-fetch (CVE-2020-15168)

Severity: low

Impact

Node Fetch did not honor the size option after following a redirect, which means that when a content size was over the limit, a FetchError would never get thrown and the process would end without failure.

For most people, this fix will have a little or no impact. However, if you are relying on node-fetch to gate files above a size, the impact could be significant, for example: If you don't double-check the size of the data after fetch() has completed, your JS thread could get tied up doing work on a large file (DoS) and/or cost you money in computing.

Patches

We released patched versions for both stable and beta channels:

Workarounds

None, it is strongly recommended to update as soon as possible.

For more information

If you have any questions or comments about this advisory: * Open an issue in node-fetch * Contact one of the core maintainers.

Affected repositories (3)

#1005439: xmldom (CVE-2021-21366)

Severity: low

Impact

xmldom versions 0.4.0 and older do not correctly preserve system identifiers, FPIs or namespaces when repeatedly parsing and serializing maliciously crafted documents.

This may lead to unexpected syntactic changes during XML processing in some downstream applications.

Patches

Update to 0.5.0 (once it is released)

Workarounds

Downstream applications can validate the input and reject the maliciously crafted documents.

References

Similar to this one reported on the Go standard library:

For more information

If you have any questions or comments about this advisory:

Affected repositories (1)

#1005560: node-fetch (CVE-2020-15168)

Severity: low

Impact

Node Fetch did not honor the size option after following a redirect, which means that when a content size was over the limit, a FetchError would never get thrown and the process would end without failure.

For most people, this fix will have a little or no impact. However, if you are relying on node-fetch to gate files above a size, the impact could be significant, for example: If you don't double-check the size of the data after fetch() has completed, your JS thread could get tied up doing work on a large file (DoS) and/or cost you money in computing.

Patches

We released patched versions for both stable and beta channels:

Workarounds

None, it is strongly recommended to update as soon as possible.

For more information

If you have any questions or comments about this advisory: * Open an issue in node-fetch * Contact one of the core maintainers.

Affected repositories (1)
Source code is licensed under the AGPL.