vulnerabilities in npm dependencies

ugh, npm.

There are 151 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)

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

#1002813: netmask (CVE-2021-28918)

Severity: critical

Improper input validation of octal strings in netmask npm package v1.0.6 and below allows unauthenticated remote attackers to perform indeterminate SSRF, RFI, and LFI attacks on many of the dependent packages. A remote unauthenticated attacker can bypass packages relying on netmask to filter IPs and reach critical VPN or LAN hosts.

:exclamation: NOTE: The fix for this issue was incomplete. A subsequent fix was made in version 2.0.1 which was assigned CVE-2021-29418 / GHSA-pch5-whg9-qr2r. For complete protection from this vulnerability an upgrade to version 2.0.1 or later is recommended.

Affected repositories (1)

#1004283: lodash.template (CVE-2019-10744)

Severity: critical

Versions of lodash before 4.17.12 are vulnerable to Prototype Pollution. The function defaultsDeep allows a malicious user to modify the prototype of Object via {constructor: {prototype: {...}}} causing the addition or modification of an existing property that will exist on all objects.

Recommendation

Update to version 4.17.12 or later.

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)

#1004735: getobject (CVE-2020-28282)

Severity: critical

Prototype pollution vulnerability in 'getobject' version 0.1.0 allows an attacker to cause a denial of service and may lead to remote code execution.

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

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

#1006307: lodash.template (CVE-2019-10744)

Severity: critical

Versions of lodash before 4.17.12 are vulnerable to Prototype Pollution. The function defaultsDeep allows a malicious user to modify the prototype of Object via {constructor: {prototype: {...}}} causing the addition or modification of an existing property that will exist on all objects.

Recommendation

Update to version 4.17.12 or later.

Affected repositories (2)

#1002424: object-path (CVE-2021-3805)

Severity: high

object-path is vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

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

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

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

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

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

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

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

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

#1002525: pac-resolver (CVE-2021-23406)

Severity: high

This affects the package pac-resolver before 5.0.0. This can occur when used with untrusted input, due to unsafe PAC file handling. NOTE: The fix for this vulnerability is applied in the node-degenerator library, a dependency written by the same maintainer.

Affected repositories (1)

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

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

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

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

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

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

#1002578: normalize-url (CVE-2021-33502)

Severity: high

The normalize-url package before 4.5.1, 5.x before 5.3.1, and 6.x before 6.0.1 for Node.js has a ReDoS (regular expression denial of service) issue because it has exponential performance for data: URLs.

Affected repositories (2)

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

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

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

#1002735: grunt (CVE-2020-7729)

Severity: high

The package grunt before 1.3.0 are vulnerable to Arbitrary Code Execution due to the default usage of the function load() instead of its secure replacement safeLoad() of the package js-yaml inside grunt.file.readYAML.

Affected repositories (1)

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

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

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

#1002899: merge (CVE-2020-28499)

Severity: high

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

Affected repositories (5)

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

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

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

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

#1004063: lodash (CVE-2020-8203)

Severity: high

Versions of lodash prior to 4.17.19 are vulnerable to Prototype Pollution. The function zipObjectDeep allows a malicious user to modify the prototype of Object if the property identifiers are user-supplied. Being affected by this issue requires zipping objects based on user-provided property arrays.

This vulnerability causes the addition or modification of an existing property that will exist on all objects and may lead to Denial of Service or Code Execution under specific circumstances.

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)

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

#1005024: immer (CVE-2021-3757)

Severity: high

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

Affected repositories (1)

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

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

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

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

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

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

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

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

#1005356: aws-sdk (CVE-2020-28472)

Severity: high

This affects the package @aws-sdk/shared-ini-file-loader before 1.0.0-rc.9; the package aws-sdk before 2.814.0. If an attacker submits a malicious INI file to an application that parses it with loadSharedConfigFiles , they will pollute the prototype on the application. This can be exploited further depending on the context.

Affected repositories (1)

#1005365: lodash (CVE-2021-23337)

Severity: high

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

Affected repositories (3)

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

#1005415: merge (CVE-2020-28499)

Severity: high

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

Affected repositories (2)

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

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

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

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

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

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

#1006094: lodash (CVE-2020-8203)

Severity: high

Versions of lodash prior to 4.17.19 are vulnerable to Prototype Pollution. The function zipObjectDeep allows a malicious user to modify the prototype of Object if the property identifiers are user-supplied. Being affected by this issue requires zipping objects based on user-provided property arrays.

This vulnerability causes the addition or modification of an existing property that will exist on all objects and may lead to Denial of Service or Code Execution under specific circumstances.

Affected repositories (1)

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

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

#1006865: follow-redirects (CVE-2022-0155)

Severity: high

follow-redirects is vulnerable to Exposure of Private Personal Information to an Unauthorized Actor

Affected repositories (5)

#1006870: engine.io (CVE-2022-21676)

Severity: high

Impact

A specially crafted HTTP request can trigger an uncaught exception on the Engine.IO server, thus killing the Node.js process.

RangeError: Invalid WebSocket frame: RSV2 and RSV3 must be clear at Receiver.getInfo (/.../node_modules/ws/lib/receiver.js:176:14) at Receiver.startLoop (/.../node_modules/ws/lib/receiver.js:136:22) at Receiver._write (/.../node_modules/ws/lib/receiver.js:83:10) at writeOrBuffer (internal/streams/writable.js:358:12)

This impacts all the users of the engine.io package starting from version 4.0.0, including those who uses depending packages like socket.io.

Patches

A fix has been released for each major branch:

| Version range | Fixed version | | --- | --- | | engine.io@4.x.x | 4.1.2 | | engine.io@5.x.x | 5.2.1 | | engine.io@6.x.x | 6.1.1 |

Previous versions (< 4.0.0) are not impacted.

For socket.io users:

| Version range | engine.io version | Needs minor update? | | --- | --- | --- | | socket.io@4.4.x | ~6.1.0 | - | socket.io@4.3.x | ~6.0.0 | Please upgrade to socket.io@4.4.x | socket.io@4.2.x | ~5.2.0 | - | socket.io@4.1.x | ~5.1.1 | Please upgrade to socket.io@4.4.x | socket.io@4.0.x | ~5.0.0 | Please upgrade to socket.io@4.4.x | socket.io@3.1.x | ~4.1.0 | - | socket.io@3.0.x | ~4.0.0 | Please upgrade to socket.io@3.1.x or socket.io@4.4.x (see here)

In most cases, running npm audit fix should be sufficient. You can also use npm update engine.io --depth=9999.

Workarounds

There is no known workaround except upgrading to a safe version.

For more information

If you have any questions or comments about this advisory:

Thanks to Marcus Wejderot from Mevisio for the responsible disclosure.

Affected repositories (3)

#1006872: engine.io (CVE-2022-21676)

Severity: high

Impact

A specially crafted HTTP request can trigger an uncaught exception on the Engine.IO server, thus killing the Node.js process.

RangeError: Invalid WebSocket frame: RSV2 and RSV3 must be clear at Receiver.getInfo (/.../node_modules/ws/lib/receiver.js:176:14) at Receiver.startLoop (/.../node_modules/ws/lib/receiver.js:136:22) at Receiver._write (/.../node_modules/ws/lib/receiver.js:83:10) at writeOrBuffer (internal/streams/writable.js:358:12)

This impacts all the users of the engine.io package starting from version 4.0.0, including those who uses depending packages like socket.io.

Patches

A fix has been released for each major branch:

| Version range | Fixed version | | --- | --- | | engine.io@4.x.x | 4.1.2 | | engine.io@5.x.x | 5.2.1 | | engine.io@6.x.x | 6.1.1 |

Previous versions (< 4.0.0) are not impacted.

For socket.io users:

| Version range | engine.io version | Needs minor update? | | --- | --- | --- | | socket.io@4.4.x | ~6.1.0 | - | socket.io@4.3.x | ~6.0.0 | Please upgrade to socket.io@4.4.x | socket.io@4.2.x | ~5.2.0 | - | socket.io@4.1.x | ~5.1.1 | Please upgrade to socket.io@4.4.x | socket.io@4.0.x | ~5.0.0 | Please upgrade to socket.io@4.4.x | socket.io@3.1.x | ~4.1.0 | - | socket.io@3.0.x | ~4.0.0 | Please upgrade to socket.io@3.1.x or socket.io@4.4.x (see here)

In most cases, running npm audit fix should be sufficient. You can also use npm update engine.io --depth=9999.

Workarounds

There is no known workaround except upgrading to a safe version.

For more information

If you have any questions or comments about this advisory:

Thanks to Marcus Wejderot from Mevisio for the responsible disclosure.

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

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

#1006893: shelljs (CVE-2022-0144)

Severity: high

shelljs is vulnerable to Improper Privilege Management

Affected repositories (1)

#1006899: node-fetch (CVE-2022-0235)

Severity: high

node-fetch is vulnerable to Exposure of Sensitive Information to an Unauthorized Actor

Affected repositories (1)

#1770: tar (CVE-2021-32804)

Severity: high

The tar package has a high severity vulnerability before versions 3.2.2, 4.4.14, 5.0.6, and 6.1.1.

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.

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)

#1771: tar (CVE-2021-32803)

Severity: high

The tar package has a high severity vulnerability before versions 3.2.3, 4.4.15, 5.0.7, and 6.1.2.

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.

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)

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

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

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

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

Severity: moderate

ansi-regex is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (20)

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

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

Severity: moderate

nth-check is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (6)

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

#1002513: object-path (CVE-2021-23434)

Severity: moderate

This affects the package object-path before 0.11.6. A type confusion vulnerability can lead to a bypass of CVE-2020-15256 when the path components used in the path parameter are arrays. In particular, the condition currentPath === 'proto' returns false if currentPath is ['proto']. This is because the === operator returns always false when the type of the operands is different.

Affected repositories (1)

#1002521: trim-off-newlines (CVE-2021-23425)

Severity: moderate

All versions of package trim-off-newlines are vulnerable to Regular Expression Denial of Service (ReDoS) via string processing.

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

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

#1002635: 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 (5)

#1002692: hosted-git-info (CVE-2021-23362)

Severity: moderate

The npm package hosted-git-info before 3.0.8 are vulnerable to Regular Expression Denial of Service (ReDoS) via regular expression shortcutMatch in the fromUrl function in index.js. The affected regular expression exhibits polynomial worst-case time complexity

Affected repositories (4)

#1002874: netmask (CVE-2021-29418)

Severity: moderate

The netmask package before 2.0.1 for Node.js mishandles certain unexpected characters in an IP address string, such as an octal digit of 9. This (in some situations) allows attackers to bypass access control that is based on IP addresses. NOTE: this issue exists because of an incomplete fix for CVE-2021-28918.

Affected repositories (1)

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

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

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

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

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

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

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

#1004784: validator (CVE-2021-3765)

Severity: moderate

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

Affected repositories (3)

#1004876: validator (CVE-2021-3765)

Severity: moderate

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

Affected repositories (1)

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

Severity: moderate

ansi-regex is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (25)

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

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

Severity: moderate

nth-check is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (4)

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

Severity: moderate

npm semver-regex is vulnerable to Inefficient Regular Expression Complexity

Affected repositories (1)

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

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

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

#1005115: striptags (CVE-2021-32696)

Severity: moderate

A type-confusion vulnerability can cause striptags to concatenate unsanitized strings when an array-like object is passed in as the html parameter. This can be abused by an attacker who can control the shape of their input, e.g. if query parameters are passed directly into the function.

Impact

XSS

Patches

3.2.0

Workarounds

Ensure that the html parameter is a string before calling the function.

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)

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

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

#1005210: hosted-git-info (CVE-2021-23362)

Severity: moderate

The npm package hosted-git-info before 3.0.8 are vulnerable to Regular Expression Denial of Service (ReDoS) via regular expression shortcutMatch in the fromUrl function in index.js. The affected regular expression exhibits polynomial worst-case time complexity

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)

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

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

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

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

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

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

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

Severity: moderate

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

Affected repositories (20)

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

#1006767: swagger-ui-dist

Severity: moderate

SwaggerUI supports displaying remote OpenAPI definitions through the ?url parameter. This enables robust demonstration capabilities on sites like petstore.swagger.io, editor.swagger.io, and similar sites, where users often want to see what their OpenAPI definitions would look like rendered.

However, this functionality may pose a risk for users who host their own SwaggerUI instances. In particular, including remote OpenAPI definitions opens a vector for phishing attacks by abusing the trusted names/domains of self-hosted instances.

An example scenario abusing this functionality could take the following form: - https://example.com/api-docs hosts a version of SwaggerUI with ?url= query parameter enabled. - Users will trust the domain https://example.com and the contents of the OpenAPI definition. - A malicious actor may craft a similar OpenAPI definition and service that responds to the defined APIs at https://evildomain. - Users mistakenly click a phishing URL like https://example.com/api-docs?url=https://evildomain/fakeapi.yaml and enters sensitive data via the "Try-it-out" feature.

We do want to stress that this attack vector is limited to scenarios that actively trick users into divulging sensitive information. The ease of this is highly contextual and, therefore, the threat model may be different for individual users and organizations. It is not possible to perform non-interactive attacks (e.g., cross-site scripting or code injection) through this mechanism.

Resolution

We've made the decision to disable query parameters (#4872) by default starting with SwaggerUI version 4.1.3. Please update to this version when it becomes available (ETA: 2021 December). Users will still be able to be re-enable the options at their discretion. We'll continue to enable query parameters on the Swagger demo sites.

Workaround

If you host a version of SwaggerUI and wish to mitigate this issue immediately, you are encouraged to add the following custom plugin code:

js SwaggerUI({ // ...other configuration options, plugins: [function UrlParamDisablePlugin() { return { statePlugins: { spec: { wrapActions: { // Remove the ?url parameter from loading an external OpenAPI definition. updateUrl: (oriAction) => (payload) => { const url = new URL(window.location.href) if (url.searchParams.has('url')) { url.searchParams.delete('url') window.location.replace(url.toString()) } return oriAction(payload) } } } } } }], })

Future UX work

Through the exploration of this issue, it became apparent that users may not be aware to which web server the Try-it-out function will send requests. While this information is currently presented at the top of the page, understanding may improve by displaying it closer to the "Execute" button where requests are actually made. We'll be exploring these UX improvements over the coming months and welcome community input. Please create a Feature Request under the GitHub Issue tab to start a conversation with us and the community.

Affected repositories (5)

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

#1006841: lodash (CVE-2020-28500)

Severity: moderate

All versions of package lodash prior to 4.17.21 are vulnerable to Regular Expression Denial of Service (ReDoS) via the toNumber, trim and trimEnd functions. Steps to reproduce (provided by reporter Liyuan Chen): var lo = require('lodash'); function build_blank (n) { var ret = "1" for (var i = 0; i < n; i++) { ret += " " } return ret + "1"; } var s = build_blank(50000) var time0 = Date.now(); lo.trim(s) var time_cost0 = Date.now() - time0; console.log("time_cost0: " + time_cost0) var time1 = Date.now(); lo.toNumber(s) var time_cost1 = Date.now() - time1; console.log("time_cost1: " + time_cost1) var time2 = Date.now(); lo.trimEnd(s) var time_cost2 = Date.now() - time2; console.log("time_cost2: " + time_cost2)

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

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

#1006892: log4js (CVE-2022-21704)

Severity: moderate

Impact

Default file permissions for log files created by the file, fileSync and dateFile appenders are world-readable (in unix). This could cause problems if log files contain sensitive information. This would affect any users that have not supplied their own permissions for the files via the mode parameter in the config.

Patches

Fixed by: * https://github.com/log4js-node/log4js-node/pull/1141 * https://github.com/log4js-node/streamroller/pull/87

Released to NPM in log4js@6.4.0

Workarounds

Every version of log4js published allows passing the mode parameter to the configuration of file appenders, see the documentation for details.

References

Thanks to ranjit-git for raising the issue, and to @peteriman for fixing the problem.

For more information

If you have any questions or comments about this advisory: * Open an issue in logj4s-node * Ask a question in the slack channel * Email us at gareth.nomiddlename@gmail.com

Affected repositories (4)

#1006897: nanoid (CVE-2021-23566)

Severity: moderate

The package nanoid before 3.1.31 are vulnerable to Information Exposure via the valueOf() function which allows to reproduce the last id generated.

Affected repositories (16)

#1675: sanitize-html (CVE-2021-26539)

Severity: moderate

sanitize-html before 2.3.1 does not properly handle internationalized domain name (IDN) which could allow an attacker to bypass hostname whitelist validation set by the "allowedIframeHostnames" option.

Affected repositories (1)

#1676: sanitize-html (CVE-2021-26540)

Severity: moderate

sanitize-html before 2.3.2 does not properly validate the hostnames set by the "allowedIframeHostnames" option when the "allowIframeRelativeUrls" is set to true, which allows attackers to bypass hostname whitelist for iframe element, related using an src value that starts with "/\example.com".

Affected repositories (1)

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

#1005277: redis (CVE-2021-29469)

Severity: low

Impact

When a client is in monitoring mode, the regex begin used to detected monitor messages could cause exponential backtracking on some strings. This issue could lead to a denial of service.

Patches

The problem was fixed in commit 2d11b6d and was released in version 3.1.1.

References

1569 (GHSL-2021-026)

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

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

#1006342: braces

Severity: low

Versions of braces prior to 2.3.1 are vulnerable to Regular Expression Denial of Service (ReDoS). Untrusted input may cause catastrophic backtracking while matching regular expressions. This can cause the application to be unresponsive leading to Denial of Service.

Recommendation

Upgrade to version 2.3.1 or higher.

Affected repositories (1)

#1179: minimist

Severity: low

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.

Affected repositories (1)

#1589: ini

Severity: low

ini before version 1.3.6 has a Prototype Pollution vulnerability.

Impact

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 (1)
Source code is licensed under the AGPL.