vulnerabilities in npm dependencies

ugh, npm.

There are 73 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 (3)

#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)

#1005029: 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 (2)

#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)

#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 (3)

#1002477: axios (CVE-2021-3749)

Severity: high

axios is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (2)

#1002487: immer (CVE-2021-3757)

Severity: high

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

Affected repositories (3)

#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 (3)

#1002612: css-what (CVE-2021-33587)

Severity: high

The css-what package 4.0.0 through 5.0.0 for Node.js does not ensure that attribute parsing has Linear Time Complexity relative to the size of the input.

Affected repositories (1)

#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 (2)

#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 (4)

#1002775: trim (CVE-2020-7753)

Severity: high

All versions of package trim lower than 0.0.3 are vulnerable to Regular Expression Denial of Service (ReDoS) via trim().

Affected repositories (1)

#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)

#1005018: axios (CVE-2021-3749)

Severity: high

axios is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (2)

#1005024: immer (CVE-2021-3757)

Severity: high

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

Affected repositories (2)

#1005040: 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 (1)

#1005043: 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 (1)

#1005046: 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 (1)

#1005059: 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 (2)

#1005078: 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)

#1005082: 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)

#1005111: 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 (2)

#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 (4)

#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 (1)

#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)

#1005427: 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 (1)

#1005460: 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 (2)

#1005489: 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 (2)

#1005557: 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)

#1006074: 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 (2)

#1006326: 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)

#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)

#1006883: marked (CVE-2022-21681)

Severity: high

Impact

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.

```javascript 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.

Patches

Has the problem been patched?

Yes

What versions should users upgrade to?

4.0.10

Workarounds

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.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Affected repositories (2)

#1006884: marked (CVE-2022-21680)

Severity: high

Impact

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.

```javascript 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.

Patches

Has the problem been patched?

Yes

What versions should users upgrade to?

4.0.10

Workarounds

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.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Affected repositories (2)

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

Severity: moderate

ansi-regex is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (10)

#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 (2)

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

Severity: moderate

nth-check is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (4)

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

Severity: moderate

npm semver-regex is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (1)

#1002466: tmpl (CVE-2021-3777)

Severity: moderate

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

Affected repositories (1)

#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 (1)

#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 (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 (1)

#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 (1)

#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 (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)

#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)

#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 (1)

#1004784: validator (CVE-2021-3765)

Severity: moderate

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

Affected repositories (8)

#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 (13)

#1004966: 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 (2)

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

Severity: moderate

nth-check is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (3)

#1005010: tmpl (CVE-2021-3777)

Severity: moderate

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

Affected repositories (3)

#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)

#1005112: 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)

#1005125: 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 (1)

#1005174: 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 (2)

#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)

#1005441: 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 (2)

#1005512: 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)

#1005528: 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 (2)

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

Severity: moderate

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

Affected repositories (7)

#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)

#1006820: 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.7.0)

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)

#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 (177)

#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 (2)

#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 (1)

#1006886: 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)

#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 (2)

#1005531: 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 (2)

#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.