pkg:npm\/ansi-html@0.0.7
HIGH
CVE-2021-23424
https:\/\/ossindex.sonatype.org\/vulnerability\/849e9fed-44e8-4593-a4ca-61026c4b454f?component-type=npm&component-name=ansi-html&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
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.
pkg:npm\/ansi-html@0.0.7
high
1005059
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.
pkg:npm\/axios@0.19.2
high
1005018
axios is vulnerable to Inefficient Regular Expression Complexity
pkg:npm\/axios@0.19.2
high
1005506
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.
pkg:npm\/axios@0.19.2
HIGH
CVE-2021-3749
https:\/\/ossindex.sonatype.org\/vulnerability\/b8488bde-055b-4c39-831a-f81d10fe6940?component-type=npm&component-name=axios&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
axios is vulnerable to Inefficient Regular Expression Complexity
pkg:npm\/axios@0.19.2
HIGH
CWE-918: Server-Side Request Forgery (SSRF)
https:\/\/ossindex.sonatype.org\/vulnerability\/293be0b3-9672-4e36-b530-44be7f592d0a?component-type=npm&component-name=axios&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
pkg:npm\/codemirror@5.37.0
HIGH
CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')
https:\/\/ossindex.sonatype.org\/vulnerability\/06064bb5-2b15-437c-b145-16ff54d51b1b?component-type=npm&component-name=codemirror&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.
pkg:npm\/dns-packet@1.3.1
high
1005168
This affects the package dns-packet before versions 1.3.2 and 5.2.2. It creates buffers with allocUnsafe and does not always fill them before forming network packets. This can expose internal application memory over unencrypted network when querying crafted invalid domain names.
pkg:npm\/follow-redirects@1.5.10
high
1006865
follow-redirects is vulnerable to Exposure of Private Personal Information to an Unauthorized Actor
pkg:npm\/glob-parent@5.1.1
HIGH
CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')
https:\/\/ossindex.sonatype.org\/vulnerability\/64cd5f21-8af4-4eae-ac7d-a53241ea693a?component-type=npm&component-name=glob-parent&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.
pkg:npm\/glob-parent@5.1.1
high
1005154
This affects the package glob-parent before 5.1.2. The enclosure regex used to check for strings ending in enclosure containing path separator.
pkg:npm\/hosted-git-info@2.8.8
HIGH
CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')
https:\/\/ossindex.sonatype.org\/vulnerability\/6225b8be-43bb-4407-84d3-e0179f3987bd?component-type=npm&component-name=hosted-git-info&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.
pkg:npm\/ini@1.3.5
high
1005523
### Overview\nThe `ini` npm package before version 1.3.6 has a Prototype Pollution vulnerability.\n\nIf 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.\n\n### Patches\n\nThis has been patched in 1.3.6\n\n### Steps to reproduce\n\npayload.ini\n```\n[__proto__]\npolluted = \"polluted\"\n```\n\npoc.js:\n```\nvar fs = require('fs')\nvar ini = require('ini')\n\nvar parsed = ini.parse(fs.readFileSync('.\/payload.ini', 'utf-8'))\nconsole.log(parsed)\nconsole.log(parsed.__proto__)\nconsole.log(polluted)\n```\n\n```\n> node poc.js\n{}\n{ polluted: 'polluted' }\n{ polluted: 'polluted' }\npolluted\n```
pkg:npm\/ini@1.3.5
HIGH
CWE-471: Modification of Assumed-Immutable Data (MAID)
https:\/\/ossindex.sonatype.org\/vulnerability\/c08153de-a0ad-4212-963d-3de92eaab509?component-type=npm&component-name=ini&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software does not properly protect an assumed-immutable element from being modified by an attacker.
pkg:npm\/jszip@3.5.0
HIGH
CVE-2021-23413
https:\/\/ossindex.sonatype.org\/vulnerability\/0a6a310f-7325-465c-a39d-88a74b6152a8?component-type=npm&component-name=jszip&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
This affects the package jszip before 3.7.0. Crafting a new zip file with filenames set to Object prototype values (e.g __proto__, toString, etc) results in a returned object with a modified prototype instance.
pkg:npm\/lodash@4.17.20
high
1005365
`lodash` versions prior to 4.17.21 are vulnerable to Command Injection via the template function.
pkg:npm\/lodash@4.17.20
HIGH
CVE-2021-23337
https:\/\/ossindex.sonatype.org\/vulnerability\/22d2fa1f-0b1d-4240-a4c0-9954a5dc9082?component-type=npm&component-name=lodash&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
Lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function.
pkg:npm\/marked@0.7.0
high
1006883
### Impact\n\n_What kind of vulnerability is it?_\n\nDenial of service.\n\nThe regular expression `inline.reflinkSearch` may cause catastrophic backtracking against some strings.\nPoC is the following.\n\n```javascript\nimport * as marked from 'marked';\n\nconsole.log(marked.parse(`[x]: x\n\n\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](\\\\[\\\\](`));\n```\n\n_Who is impacted?_\n\nAnyone who runs untrusted markdown through marked and does not use a worker with a time limit.\n\n### Patches\n\n_Has the problem been patched?_\n\nYes\n\n_What versions should users upgrade to?_\n\n4.0.10\n\n### Workarounds\n\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nDo not run untrusted markdown through marked or run marked on a [worker](https:\/\/marked.js.org\/using_advanced#workers) thread and set a reasonable time limit to prevent draining resources.\n\n### References\n\n_Are there any links users can visit to find out more?_\n\n- https:\/\/marked.js.org\/using_advanced#workers\n- https:\/\/owasp.org\/www-community\/attacks\/Regular_expression_Denial_of_Service_-_ReDoS\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [marked](https:\/\/github.com\/markedjs\/marked)\n
pkg:npm\/marked@0.7.0
HIGH
CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')
https:\/\/ossindex.sonatype.org\/vulnerability\/0b40743e-40d7-4745-973a-58ecc27837d7?component-type=npm&component-name=marked&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.
pkg:npm\/minimist@0.0.8
HIGH
CWE-94: Improper Control of Generation of Code ('Code Injection')
https:\/\/ossindex.sonatype.org\/vulnerability\/a0172c09-270c-4d3c-9816-564f20f372db?component-type=npm&component-name=minimist&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
pkg:javascript\/jquery@3.4.1.min
MEDIUM
CVE-2020-11023
https:\/\/lists.apache.org\/thread.html\/r9006ad2abf81d02a0ef2126bab5177987e59095b7194a487c4ea247c@%3Ccommits.felix.apache.org%3E
In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing elements 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. This problem is patched in jQuery 3.5.0.
pkg:javascript\/jquery@3.4.1.min
MEDIUM
CVE-2020-11022
https:\/\/www.oracle.com\/security-alerts\/cpuoct2020.html
In jQuery versions greater than or equal to 1.2 and before 3.5.0, 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. This problem is patched in jQuery 3.5.0.
pkg:javascript\/YUI@2.9.0
MEDIUM
CVE-2012-5882
http:\/\/www.securityfocus.com\/bid\/56385
Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.5.0 through 2.9.0 allows remote attackers to inject arbitrary web script or HTML via vectors related to uploader.swf, a similar issue to CVE-2010-4208.
pkg:javascript\/YUI@2.9.0
MEDIUM
CVE-2012-5883
http:\/\/www.bugzilla.org\/security\/3.6.11\/
Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.8.0 through 2.9.0, as used in Bugzilla 3.7.x and 4.0.x before 4.0.9, 4.1.x and 4.2.x before 4.2.4, and 4.3.x and 4.4.x before 4.4rc1, allows remote attackers to inject arbitrary web script or HTML via vectors related to swfstore.swf, a similar issue to CVE-2010-4209.
pkg:javascript\/YUI@2.9.0
MEDIUM
CVE-2012-5882
http:\/\/www.securityfocus.com\/bid\/56385
Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.5.0 through 2.9.0 allows remote attackers to inject arbitrary web script or HTML via vectors related to uploader.swf, a similar issue to CVE-2010-4208.
pkg:javascript\/YUI@2.9.0
MEDIUM
CVE-2012-5881
http:\/\/www.securityfocus.com\/bid\/56385
Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.4.0 through 2.9.0 allows remote attackers to inject arbitrary web script or HTML via vectors related to charts.swf, a similar issue to CVE-2010-4207.
pkg:javascript\/YUI@2.9.0
MEDIUM
CVE-2012-5883
http:\/\/www.bugzilla.org\/security\/3.6.11\/
Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.8.0 through 2.9.0, as used in Bugzilla 3.7.x and 4.0.x before 4.0.9, 4.1.x and 4.2.x before 4.2.4, and 4.3.x and 4.4.x before 4.4rc1, allows remote attackers to inject arbitrary web script or HTML via vectors related to swfstore.swf, a similar issue to CVE-2010-4209.
pkg:javascript\/YUI@2.9.0
MEDIUM
CVE-2012-5881
http:\/\/www.securityfocus.com\/bid\/56385
Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.4.0 through 2.9.0 allows remote attackers to inject arbitrary web script or HTML via vectors related to charts.swf, a similar issue to CVE-2010-4207.
pkg:javascript\/YUI@2.9.0
MEDIUM
CVE-2012-5881
http:\/\/www.securityfocus.com\/bid\/56385
Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.4.0 through 2.9.0 allows remote attackers to inject arbitrary web script or HTML via vectors related to charts.swf, a similar issue to CVE-2010-4207.
pkg:javascript\/YUI@2.9.0
MEDIUM
CVE-2012-5882
http:\/\/www.securityfocus.com\/bid\/56385
Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.5.0 through 2.9.0 allows remote attackers to inject arbitrary web script or HTML via vectors related to uploader.swf, a similar issue to CVE-2010-4208.
pkg:javascript\/YUI@2.9.0
MEDIUM
CVE-2012-5882
http:\/\/www.securityfocus.com\/bid\/56385
Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.5.0 through 2.9.0 allows remote attackers to inject arbitrary web script or HTML via vectors related to uploader.swf, a similar issue to CVE-2010-4208.
pkg:javascript\/YUI@2.9.0
MEDIUM
CVE-2012-5883
http:\/\/www.bugzilla.org\/security\/3.6.11\/
Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.8.0 through 2.9.0, as used in Bugzilla 3.7.x and 4.0.x before 4.0.9, 4.1.x and 4.2.x before 4.2.4, and 4.3.x and 4.4.x before 4.4rc1, allows remote attackers to inject arbitrary web script or HTML via vectors related to swfstore.swf, a similar issue to CVE-2010-4209.
pkg:javascript\/YUI@2.9.0
MEDIUM
CVE-2012-5881
http:\/\/www.securityfocus.com\/bid\/56385
Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.4.0 through 2.9.0 allows remote attackers to inject arbitrary web script or HTML via vectors related to charts.swf, a similar issue to CVE-2010-4207.
pkg:javascript\/YUI@2.9.0
MEDIUM
CVE-2012-5883
http:\/\/www.bugzilla.org\/security\/3.6.11\/
Cross-site scripting (XSS) vulnerability in the Flash component infrastructure in YUI 2.8.0 through 2.9.0, as used in Bugzilla 3.7.x and 4.0.x before 4.0.9, 4.1.x and 4.2.x before 4.2.4, and 4.3.x and 4.4.x before 4.4rc1, allows remote attackers to inject arbitrary web script or HTML via vectors related to swfstore.swf, a similar issue to CVE-2010-4209.
pkg:npm\/ansi-regex@4.1.0
moderate
1004946
ansi-regex is vulnerable to Inefficient Regular Expression Complexity
pkg:npm\/axios@0.19.2
MEDIUM
CVE-2020-28168
https:\/\/ossindex.sonatype.org\/vulnerability\/f7fc0998-d7c0-4f98-aba5-661f7db01bfd?component-type=npm&component-name=axios&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
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.
pkg:npm\/codemirror@5.37.0
moderate
1005293
This affects the package codemirror before 5.58.2; the package org.apache.marmotta.webjars:codemirror before 5.58.2.\n 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|\/*.*?*\/)*
pkg:npm\/elliptic@6.5.3
moderate
1005443
The npm package `elliptic` before version 6.5.4 are vulnerable to Cryptographic Issues via the secp256k1 implementation in elliptic\/ec\/key.js. There is no check to confirm that the public key point passed into the derive function actually exists on the secp256k1 curve. This results in the potential for the private key used in this implementation to be revealed after a number of ECDH operations are performed.
pkg:npm\/hosted-git-info@2.8.8
moderate
1005210
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
pkg:npm\/hosted-git-info@2.8.8
MEDIUM
CVE-2021-23362
https:\/\/ossindex.sonatype.org\/vulnerability\/f16accd0-1194-4dfb-b658-295f0edeb695?component-type=npm&component-name=hosted-git-info&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The 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.
pkg:npm\/json-schema@0.2.3
moderate
1006724
json-schema is vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
pkg:npm\/jszip@3.5.0
MEDIUM
CVE-2021-23413
https:\/\/snyk.io\/vuln\/SNYK-JS-JSZIP-1251497
This affects the package jszip before 3.7.0. Crafting a new zip file with filenames set to Object prototype values (e.g __proto__, toString, etc) results in a returned object with a modified prototype instance.
pkg:npm\/jszip@3.5.0
moderate
1005083
This affects the package jszip before 3.7.0. Crafting a new zip file with filenames set to Object prototype values (e.g __proto__, toString, etc) results in a returned object with a modified prototype instance.
pkg:npm\/lodash@4.17.20
MEDIUM
CVE-2020-28500
https:\/\/ossindex.sonatype.org\/vulnerability\/1ce7eaac-c691-4996-b7ed-2a870b287f33?component-type=npm&component-name=lodash&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
Lodash versions prior to 4.17.21 are vulnerable to Regular Expression Denial of Service (ReDoS) via the toNumber, trim and trimEnd functions.
pkg:npm\/elliptic@6.5.3
LOW
[NPMJS]Use of a Broken or Risky Cryptographic Algorithm
https:\/\/ossindex.sonatype.org\/vulnerability\/d445fb2b-0a67-46ac-bdc5-b2e27a53c2d3?component-type=npm&component-name=elliptic&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
elliptic before version 6.5.4 is vulnerable to Cryptographic Issues via the secp256k1 implementation in elliptic\/ec\/key.js. There is no check to confirm that the public key point passed into the derive function actually exists on the secp256k1 curve. This results in the potential for the private key used in this implementation to be revealed after a number of ECDH operations are performed. > -- [npmjs.com](https:\/\/www.npmjs.com\/advisories\/1648)
pkg:npm\/jsrsasign@8.0.24
critical
1005328
### Impact\nVulnerable jsrsasign will accept RSA signature with improper PKCS#1.5 padding.\nDecoded RSA signature value consists following form:\n01(ff...(8 or more ffs)...ff)00[ASN.1 OF DigestInfo]\nIts byte length shall be the same as RSA key length however such checking was not sufficient.\n\nTo make crafted message for practical attack is very hard.\n\n### Patches\nUsers validating RSA signature should upgrade to 10.2.0 or later.\n\n### Workarounds\nThere is no workaround. Not to use RSA signature validation in jsrsasign.\n\n### ACKNOWLEDGEMENT\nThanks to Daniel Yahyazadeh @yahyazadeh for reporting and analyzing this vulnerability.
pkg:npm\/lodash@4.17.20
CRITICAL
CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
https:\/\/ossindex.sonatype.org\/vulnerability\/2053350d-b06f-4926-88ea-871760f6e5d8?component-type=npm&component-name=lodash&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component.
pkg:npm\/minimist@0.0.8
moderate
1006180
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. \nParsing 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. \nThis is exploitable if attackers have control over the arguments being passed to `minimist`.\n\n\n\n## Recommendation\n\nUpgrade to versions 0.2.1, 1.2.3 or later.
pkg:npm\/nanoid@2.1.11
MEDIUM
CVE-2021-23566
https:\/\/gist.github.com\/artalar\/bc6d1eb9a3477d15d2772e876169a444
The package nanoid from 3.0.0 and before 3.1.31 are vulnerable to Information Exposure via the valueOf() function which allows to reproduce the last id generated.
pkg:npm\/nanoid@2.1.11
moderate
1006897
The package nanoid before 3.1.31 are vulnerable to Information Exposure via the valueOf() function which allows to reproduce the last id generated.
pkg:npm\/node-fetch@2.6.1
high
1006899
node-fetch is vulnerable to Exposure of Sensitive Information to an Unauthorized Actor
pkg:npm\/path-parse@1.0.5
HIGH
CVE-2021-23343
https:\/\/ossindex.sonatype.org\/vulnerability\/c8574971-0fcc-4713-b46b-b3aebd4394ef?component-type=npm&component-name=path-parse&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
All versions of 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.
pkg:npm\/socket.io-parser@3.4.1
high
1005107
The `socket.io-parser` npm package before versions 3.3.2 and 3.4.1 allows attackers to cause a denial of service (memory consumption) via a large packet because a concatenation approach is used.
pkg:npm\/ssri@8.0.0
high
1005323
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.
pkg:npm\/ssri@8.0.0
HIGH
CVE-2021-27290
https:\/\/ossindex.sonatype.org\/vulnerability\/92bbcbaf-097a-43f9-855e-2052e38930db?component-type=npm&component-name=ssri&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
ssri 5.2.2-8.0.0, fixed in 8.0.1, 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.
pkg:npm\/ssri@8.0.0
high
1005180
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.
pkg:npm\/tar@4.4.13
high
1005046
### Impact\n\nArbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution\n\n`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.\n\nThis 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.\n\nBy 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.\n\nAdditionally, 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. \n\nThese issues were addressed in releases 4.4.16, 5.0.8 and 6.1.7.\n\nThe 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.\n\n### Patches\n\n4.4.16 || 5.0.8 || 6.1.7\n\n### Workarounds\n\nUsers may work around this vulnerability without upgrading by creating a custom filter method which prevents the extraction of symbolic links.\n\n```js\nconst tar = require('tar')\n\ntar.x({\n file: 'archive.tgz',\n filter: (file, entry) => {\n if (entry.type === 'SymbolicLink') {\n return false\n } else {\n return true\n }\n }\n})\n```\n\nUsers are encouraged to upgrade to the latest patched versions, rather than attempt to sanitize tar input themselves.\n\n### Fix\n\nThe problem is addressed in the following ways:\n\n1. 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.\n2. 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.\n\n#### Caveat\n\nNote 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()`.\n\nUsers are encouraged to always normalize paths using a well-tested method such as `path.resolve()` before comparing paths to one another.
pkg:npm\/tar@4.4.13
high
1005038
### Impact\n\nArbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution\n\nnode-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.\n\nThis 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.\n\nAdditionally, 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.\n\nThis only affects users of `node-tar` on Windows systems.\n\n### Patches\n\n4.4.18 || 5.0.10 || 6.1.9\n\n### Workarounds\n\nThere is no reasonable way to work around this issue without performing the same path normalization procedures that node-tar now does.\n\nUsers are encouraged to upgrade to the latest patched versions of node-tar, rather than attempt to sanitize paths themselves.\n\n### Fix\n\nThe fixed versions strip path roots from all paths prior to being resolved against the extraction target folder, even if such paths are not \"absolute\".\n\nAdditionally, 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.\n\nFinally, 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.\n
pkg:npm\/tar@4.4.13
high
1005040
### Impact\n\nArbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution\n\nnode-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.\n\nThis 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.\n\nAdditionally, 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.\n\nThis only affects users of `node-tar` on Windows systems.\n\n### Patches\n\n4.4.18 || 5.0.10 || 6.1.9\n\n### Workarounds\n\nThere is no reasonable way to work around this issue without performing the same path normalization procedures that node-tar now does.\n\nUsers are encouraged to upgrade to the latest patched versions of node-tar, rather than attempt to sanitize paths themselves.\n\n### Fix\n\nThe fixed versions strip path roots from all paths prior to being resolved against the extraction target folder, even if such paths are not \"absolute\".\n\nAdditionally, 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.\n\nFinally, 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.\n
pkg:npm\/tar@4.4.13
high
1005044
### Impact\n\nArbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution\n\n`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.\n\nThis 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.\n\nBy 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.\n\nAdditionally, 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. \n\nThese issues were addressed in releases 4.4.16, 5.0.8 and 6.1.7.\n\nThe 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.\n\n### Patches\n\n4.4.16 || 5.0.8 || 6.1.7\n\n### Workarounds\n\nUsers may work around this vulnerability without upgrading by creating a custom filter method which prevents the extraction of symbolic links.\n\n```js\nconst tar = require('tar')\n\ntar.x({\n file: 'archive.tgz',\n filter: (file, entry) => {\n if (entry.type === 'SymbolicLink') {\n return false\n } else {\n return true\n }\n }\n})\n```\n\nUsers are encouraged to upgrade to the latest patched versions, rather than attempt to sanitize tar input themselves.\n\n### Fix\n\nThe problem is addressed in the following ways:\n\n1. 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.\n2. 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.\n\n#### Caveat\n\nNote 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()`.\n\nUsers are encouraged to always normalize paths using a well-tested method such as `path.resolve()` before comparing paths to one another.
pkg:npm\/tar@4.4.13
high
1005075
### Impact\n\nArbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution\n\n`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`. \n\nThis 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. \n\n### Patches\n\n3.2.2 || 4.4.14 || 5.0.6 || 6.1.1\n\nNOTE: an adjacent issue [CVE-2021-32803](https:\/\/github.com\/npm\/node-tar\/security\/advisories\/GHSA-r628-mhmh-qjhw) 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.\n\n### Workarounds\n\nUsers 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.\n\n```js\nconst path = require('path')\nconst tar = require('tar')\n\ntar.x({\n file: 'archive.tgz',\n \/\/ either add this function...\n onentry: (entry) => {\n if (path.isAbsolute(entry.path)) {\n entry.path = sanitizeAbsolutePathSomehow(entry.path)\n entry.absolute = path.resolve(entry.path)\n }\n },\n\n \/\/ or this one\n filter: (file, entry) => {\n if (path.isAbsolute(entry.path)) {\n return false\n } else {\n return true\n }\n }\n})\n```\n\nUsers are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.
pkg:npm\/tar@4.4.13
high
1005079
### Impact\n\nArbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution\n\n`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.\n\nThis 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.\n\nBy 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.\n\nThis issue was addressed in releases 3.2.3, 4.4.15, 5.0.7 and 6.1.2.\n\n### Patches\n\n3.2.3 || 4.4.15 || 5.0.7 || 6.1.2\n\n### Workarounds\n\nUsers may work around this vulnerability without upgrading by creating a custom `filter` method which prevents the extraction of symbolic links.\n\n```js\nconst tar = require('tar')\n\ntar.x({\n file: 'archive.tgz',\n filter: (file, entry) => {\n if (entry.type === 'SymbolicLink') {\n return false\n } else {\n return true\n }\n }\n})\n```\n\nUsers are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.
pkg:npm\/tar@4.4.13
high
1005081
### Impact\n\nArbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution\n\n`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.\n\nThis 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.\n\nBy 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.\n\nThis issue was addressed in releases 3.2.3, 4.4.15, 5.0.7 and 6.1.2.\n\n### Patches\n\n3.2.3 || 4.4.15 || 5.0.7 || 6.1.2\n\n### Workarounds\n\nUsers may work around this vulnerability without upgrading by creating a custom `filter` method which prevents the extraction of symbolic links.\n\n```js\nconst tar = require('tar')\n\ntar.x({\n file: 'archive.tgz',\n filter: (file, entry) => {\n if (entry.type === 'SymbolicLink') {\n return false\n } else {\n return true\n }\n }\n})\n```\n\nUsers are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.
pkg:npm\/tar@4.4.13
high
1005077
### Impact\n\nArbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution\n\n`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`. \n\nThis 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. \n\n### Patches\n\n3.2.2 || 4.4.14 || 5.0.6 || 6.1.1\n\nNOTE: an adjacent issue [CVE-2021-32803](https:\/\/github.com\/npm\/node-tar\/security\/advisories\/GHSA-r628-mhmh-qjhw) 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.\n\n### Workarounds\n\nUsers 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.\n\n```js\nconst path = require('path')\nconst tar = require('tar')\n\ntar.x({\n file: 'archive.tgz',\n \/\/ either add this function...\n onentry: (entry) => {\n if (path.isAbsolute(entry.path)) {\n entry.path = sanitizeAbsolutePathSomehow(entry.path)\n entry.absolute = path.resolve(entry.path)\n }\n },\n\n \/\/ or this one\n filter: (file, entry) => {\n if (path.isAbsolute(entry.path)) {\n return false\n } else {\n return true\n }\n }\n})\n```\n\nUsers are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.
pkg:npm\/tar@4.4.13
HIGH
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
https:\/\/ossindex.sonatype.org\/vulnerability\/3aef21de-3c46-4e8b-99a9-322df2a07bcd?component-type=npm&component-name=tar&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
pkg:npm\/url-parse@1.4.7
high
1005404
url-parse before 1.5.0 mishandles certain uses of backslash such as http:\\\/ and interprets the URI as a relative path.
pkg:npm\/url-parse@1.4.7
HIGH
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
https:\/\/ossindex.sonatype.org\/vulnerability\/fd5508e9-80b1-4255-8b06-c84cadbb14ac?component-type=npm&component-name=url-parse&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
pkg:npm\/xmlhttprequest-ssl@1.5.5
high
1005260
This affects the package xmlhttprequest before 1.7.0; all versions of package xmlhttprequest-ssl. Provided requests are sent synchronously (async=False on xhr.open), malicious user input flowing into xhr.send could result in arbitrary code being injected and run.
pkg:npm\/xmlhttprequest-ssl@1.5.5
HIGH
CWE-94: Improper Control of Generation of Code ('Code Injection')
https:\/\/ossindex.sonatype.org\/vulnerability\/211e3460-4ebe-4edb-84c1-d22d7fb7c872?component-type=npm&component-name=xmlhttprequest-ssl&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
pkg:npm\/xmlhttprequest-ssl@1.5.5
HIGH
CWE-295: Improper Certificate Validation
https:\/\/ossindex.sonatype.org\/vulnerability\/2da8ba16-45f2-412a-91be-dda511eeb65e?component-type=npm&component-name=xmlhttprequest-ssl&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software does not validate, or incorrectly validates, a certificate.
pkg:npm\/y18n@5.0.4
HIGH
CWE-20: Improper Input Validation
https:\/\/ossindex.sonatype.org\/vulnerability\/ef4add6f-4439-4eb8-bd0e-d040ff4ba76b?component-type=npm&component-name=y18n&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.
pkg:npm\/y18n@5.0.4
high
1005431
### Overview\n\nThe npm package `y18n` before versions 3.2.2, 4.0.1, and 5.0.5 is vulnerable to Prototype Pollution. \n\n### POC\n\n```\nconst y18n = require('y18n')();\n\ny18n.setLocale('__proto__');\ny18n.updateLocale({polluted: true});\n\nconsole.log(polluted); \/\/ true\n```\n\n### Recommendation\n\nUpgrade to version 3.2.2, 4.0.1, 5.0.5 or later.
pkg:npm\/y18n@5.0.4
high
1005430
### Overview\n\nThe npm package `y18n` before versions 3.2.2, 4.0.1, and 5.0.5 is vulnerable to Prototype Pollution. \n\n### POC\n\n```\nconst y18n = require('y18n')();\n\ny18n.setLocale('__proto__');\ny18n.updateLocale({polluted: true});\n\nconsole.log(polluted); \/\/ true\n```\n\n### Recommendation\n\nUpgrade to version 3.2.2, 4.0.1, 5.0.5 or later.
pkg:npm\/node-forge@0.10.0
moderate
1006898
parseUrl functionality in node-forge mishandles certain uses of backslash such as https:\/\\\/\\\/\\ and interprets the URI as a relative path.
pkg:npm\/path-parse@1.0.5
moderate
1005072
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.
pkg:npm\/socket.io@2.3.0
MEDIUM
CWE-346: Origin Validation Error
https:\/\/ossindex.sonatype.org\/vulnerability\/d128dda5-088d-4393-8ab8-248746af3ecf?component-type=npm&component-name=socket.io&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software does not properly verify that the source of data or communication is valid.
pkg:npm\/socket.io@2.3.0
MEDIUM
CVE-2020-28481
https:\/\/snyk.io\/vuln\/SNYK-JAVA-ORGWEBJARSBOWER-1056358
The package socket.io before 2.4.0 are vulnerable to Insecure Defaults due to CORS Misconfiguration. All domains are whitelisted by default.
pkg:npm\/socket.io@2.3.0
MEDIUM
CWE-346: Origin Validation Error
https:\/\/ossindex.sonatype.org\/vulnerability\/d128dda5-088d-4393-8ab8-248746af3ecf?component-type=npm&component-name=socket.io&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
The software does not properly verify that the source of data or communication is valid.
pkg:npm\/socket.io@2.3.0
moderate
1005490
The package socket.io before 2.4.0 are vulnerable to Insecure Defaults due to CORS Misconfiguration. All domains are whitelisted by default.
pkg:npm\/url-parse@1.4.7
MEDIUM
CVE-2021-27515
https:\/\/ossindex.sonatype.org\/vulnerability\/9199c073-7686-4425-a64e-6b999a5c9269?component-type=npm&component-name=url-parse&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
url-parse before 1.5.0 mishandles certain uses of backslash such as http:\\\/ and interprets the URI as a relative path.
pkg:npm\/url-parse@1.4.7
moderate
1005084
# Overview\n\nAffected versions of npm `url-parse` are vulnerable to URL Redirection to Untrusted Site.\n\n# Impact\n\nDepending on library usage and attacker intent, impacts may include allow\/block list bypasses, SSRF attacks, open redirects, or other undesired behavior.
pkg:npm\/url-parse@1.4.7
MEDIUM
CVE-2021-3664
https:\/\/ossindex.sonatype.org\/vulnerability\/a355ec61-a153-4f69-971a-c06f9b2601f2?component-type=npm&component-name=url-parse&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
url-parse is vulnerable to URL Redirection to Untrusted Site
pkg:npm\/ws@6.1.4
moderate
1005146
### Impact\n\nA specially crafted value of the `Sec-Websocket-Protocol` header can be used to significantly slow down a ws server.\n\n### Proof of concept\n\n```js\nfor (const length of [1000, 2000, 4000, 8000, 16000, 32000]) {\n const value = 'b' + ' '.repeat(length) + 'x';\n const start = process.hrtime.bigint();\n\n value.trim().split(\/ *, *\/);\n\n const end = process.hrtime.bigint();\n\n console.log('length = %d, time = %f ns', length, end - start);\n}\n```\n\n### Patches\n\nThe 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).\n\n### Workarounds\n\nIn 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`](https:\/\/nodejs.org\/api\/cli.html#cli_max_http_header_size_size) and\/or the [`maxHeaderSize`](https:\/\/nodejs.org\/api\/http.html#http_http_createserver_options_requestlistener) options.\n\n### Credits\n\nThe vulnerability was responsibly disclosed along with a fix in private by [Robert McLaughlin](https:\/\/github.com\/robmcl4) from University of California, Santa Barbara.\n
pkg:npm\/ws@6.1.4
MEDIUM
CVE-2021-32640
https:\/\/ossindex.sonatype.org\/vulnerability\/7b682dd5-ef07-459c-be11-50ec76c9eba2?component-type=npm&component-name=ws&utm_source=dependency-check&utm_medium=integration&utm_content=6.1.0
ws is an open source WebSocket client and server library for Node.js. A specially crafted value of the `Sec-Websocket-Protocol` header can be used to significantly slow down a ws server. The vulnerability has been fixed in ws@7.4.6 (https:\/\/github.com\/websockets\/ws\/commit\/00c425ec77993773d823f018f64a5c44e17023ff). 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`](https:\/\/nodejs.org\/api\/cli.html#cli_max_http_header_size_size) and\/or the [`maxHeaderSize`](https:\/\/nodejs.org\/api\/http.html#http_http_createserver_options_requestlistener) options.
pkg:npm\/ws@6.1.4
moderate
1005162
### Impact\n\nA specially crafted value of the `Sec-Websocket-Protocol` header can be used to significantly slow down a ws server.\n\n### Proof of concept\n\n```js\nfor (const length of [1000, 2000, 4000, 8000, 16000, 32000]) {\n const value = 'b' + ' '.repeat(length) + 'x';\n const start = process.hrtime.bigint();\n\n value.trim().split(\/ *, *\/);\n\n const end = process.hrtime.bigint();\n\n console.log('length = %d, time = %f ns', length, end - start);\n}\n```\n\n### Patches\n\nThe 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).\n\n### Workarounds\n\nIn 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`](https:\/\/nodejs.org\/api\/cli.html#cli_max_http_header_size_size) and\/or the [`maxHeaderSize`](https:\/\/nodejs.org\/api\/http.html#http_http_createserver_options_requestlistener) options.\n\n### Credits\n\nThe vulnerability was responsibly disclosed along with a fix in private by [Robert McLaughlin](https:\/\/github.com\/robmcl4) from University of California, Santa Barbara.\n
pkg:npm\/node-forge@0.10.0
low
1006854
### Impact\nThe regex used for the `forge.util.parseUrl` API would not properly parse certain inputs resulting in a parsed data structure that could lead to undesired behavior.\n\n### Patches\n`forge.util.parseUrl` and other very old related URL APIs were removed in 1.0.0 in favor of letting applications use the more modern WHATWG URL Standard API.\n\n### Workarounds\nEnsure code does not directly or indirectly call `forge.util.parseUrl` with untrusted input.\n\n### References\n- https:\/\/www.huntr.dev\/bounties\/41852c50-3c6d-4703-8c55-4db27164a4ae\/\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [forge](https:\/\/github.com\/digitalbazaar\/forge)\n* Email us at support@digitalbazaar.com\n
pkg:npm\/node-forge@0.10.0
low
1006852
### Impact\nThe `forge.debug` API had a potential prototype pollution issue if called with untrusted input. The API was only used for internal debug purposes in a safe way and never documented or advertised. It is suspected that uses of this API, if any exist, would likely not have used untrusted inputs in a vulnerable way.\n\n### Patches\nThe `forge.debug` API and related functions were removed in 1.0.0.\n\n### Workarounds\nDon't use the `forge.debug` API directly or indirectly with untrusted input.\n\n### References\n- https:\/\/www.huntr.dev\/bounties\/1-npm-node-forge\/\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [forge](https:\/\/github.com\/digitalbazaar\/forge).\n* Email us at support@digitalbazaar.com.
pkg:npm\/xmlhttprequest-ssl@1.5.5
critical
1005175
The xmlhttprequest-ssl package before 1.6.1 for Node.js disables SSL certificate validation by default, because rejectUnauthorized (when the property exists but is undefined) is considered to be false within the https.request function of Node.js. In other words, no certificate is ever rejected.