All the vulnerabilities related to the version 1.3.1 of the package
Prototype Pollution in handlebars
Versions of handlebars
prior to 4.0.14 are vulnerable to Prototype Pollution. Templates may alter an Objects' prototype, thus allowing an attacker to execute arbitrary code on the server.
For handlebars 4.1.x upgrade to 4.1.2 or later. For handlebars 4.0.x upgrade to 4.0.14 or later.
Arbitrary Code Execution in handlebars
Versions of handlebars
prior to 3.0.8 or 4.5.2 are vulnerable to Arbitrary Code Execution. The package's lookup helper fails to properly validate templates, allowing attackers to submit templates that execute arbitrary JavaScript in the system. It can be used to run arbitrary code in a server processing Handlebars templates or on a victim's browser (effectively serving as Cross-Site Scripting).
The following template can be used to demonstrate the vulnerability:
{{#with split as |a|}}
{{pop (push "alert('Vulnerable Handlebars JS');")}}
{{#with (concat (lookup join (slice 0 1)))}}
{{#each (slice 2 3)}}
{{#with (apply 0 a)}}
{{.}}
{{/with}}
{{/each}}
{{/with}}
{{/with}}
{{/with}}```
## Recommendation
Upgrade to version 3.0.8, 4.5.2 or later.
Arbitrary Code Execution in Handlebars
Handlebars before 3.0.8 and 4.x before 4.5.3 is vulnerable to Arbitrary Code Execution. The lookup helper fails to properly validate templates, allowing attackers to submit templates that execute arbitrary JavaScript. This can be used to run arbitrary code on a server processing Handlebars templates or in a victim's browser (effectively serving as XSS).
Prototype Pollution in handlebars
Versions of handlebars
prior to 3.0.8 or 4.5.3 are vulnerable to prototype pollution. It is possible to add or modify properties to the Object prototype through a malicious template. This may allow attackers to crash the application or execute Arbitrary Code in specific conditions.
Upgrade to version 3.0.8, 4.5.3 or later.
Arbitrary Code Execution in handlebars
Versions of handlebars
prior to 3.0.8 or 4.5.3 are vulnerable to Arbitrary Code Execution. The package's lookup helper fails to properly validate templates, allowing attackers to submit templates that execute arbitrary JavaScript in the system. It is due to an incomplete fix for a previous issue. This vulnerability can be used to run arbitrary code in a server processing Handlebars templates or on a victim's browser (effectively serving as Cross-Site Scripting).
Upgrade to version 3.0.8, 4.5.3 or later.
Prototype Pollution in handlebars
Versions of handlebars
prior to 3.0.8 or 4.3.0 are vulnerable to Prototype Pollution leading to Remote Code Execution. Templates may alter an Objects' __proto__
and __defineGetter__
properties, which may allow an attacker to execute arbitrary code through crafted payloads.
Upgrade to version 3.0.8, 4.3.0 or later.
Cross-Site Scripting in handlebars
Versions of handlebars
prior to 4.0.0 are affected by a cross-site scripting vulnerability when attributes in handlebar templates are not quoted.
Template:
<a href={{foo}}/>
Input:
{ 'foo' : 'test.com onload=alert(1)'}
Rendered result:
<a href=test.com onload=alert(1)/>
Update to version 4.0.0 or later. Alternatively, ensure that all attributes in handlebars templates are encapsulated with quotes.
Prototype Pollution in handlebars
The package handlebars before 4.7.7 are vulnerable to Prototype Pollution when selecting certain compiling options to compile templates coming from an untrusted source.
Remote code execution in handlebars when compiling templates
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.
Incorrect Handling of Non-Boolean Comparisons During Minification in uglify-js
Versions of uglify-js
prior to 2.4.24 are affected by a vulnerability which may cause crafted JavaScript to have altered functionality after minification.
Upgrade UglifyJS to version >= 2.4.24.
Regular Expression Denial of Service in uglify-js
Versions of uglify-js
prior to 2.6.0 are affected by a regular expression denial of service vulnerability when malicious inputs are passed into the parse()
method.
var u = require('uglify-js');
var genstr = function (len, chr) {
var result = "";
for (i=0; i<=len; i++) {
result = result + chr;
}
return result;
}
u.parse("var a = " + genstr(process.argv[2], "1") + ".1ee7;");
$ time node test.js 10000
real 0m1.091s
user 0m1.047s
sys 0m0.039s
$ time node test.js 80000
real 0m6.486s
user 0m6.229s
sys 0m0.094s
Update to version 2.6.0 or later.
Prototype Pollution in lodash
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.
Update to version 4.17.12 or later.
Prototype Pollution in lodash
Versions of lodash
before 4.17.5 are vulnerable to prototype pollution.
The vulnerable functions are 'defaultsDeep', 'merge', and 'mergeWith' which allow a malicious user to modify the prototype of Object
via __proto__
causing the addition or modification of an existing property that will exist on all objects.
Update to version 4.17.5 or later.
Prototype Pollution in lodash
Versions of lodash
before 4.17.11 are vulnerable to prototype pollution.
The vulnerable functions are 'defaultsDeep', 'merge', and 'mergeWith' which allow 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.
Update to version 4.17.11 or later.
Regular Expression Denial of Service (ReDoS) in lodash
lodash prior to 4.7.11 is affected by: CWE-400: Uncontrolled Resource Consumption. The impact is: Denial of service. The component is: Date handler. The attack vector is: Attacker provides very long strings, which the library attempts to match using a regular expression. The fixed version is: 4.7.11.
Regular Expression Denial of Service (ReDoS) in lodash
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);
Command Injection in lodash
lodash
versions prior to 4.17.21 are vulnerable to Command Injection via the template function.
Misinterpretation of malicious XML input
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.
Update to 0.5.0 (once it is released)
Downstream applications can validate the input and reject the maliciously crafted documents.
Similar to this one reported on the Go standard library:
If you have any questions or comments about this advisory:
xmldom/xmldom
npm owner ls xmldom
Misinterpretation of malicious XML input
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.
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.
Downstream applications can validate the input and reject the maliciously crafted documents.
Similar to this one reported on the Go standard library:
If you have any questions or comments about this advisory:
xmldom/xmldom
npm owner ls @xmldom/xmldom
xmldom allows multiple root nodes in a DOM
xmldom parses XML that is not well-formed because it contains multiple top level elements, and adds all root nodes to the childNodes
collection of the Document
, without reporting any error or throwing.
This breaks the assumption that there is only a single root node in the tree, which led to https://nvd.nist.gov/vuln/detail/CVE-2022-39299 and is a potential issue for dependents.
Update to @xmldom/xmldom@~0.7.7
, @xmldom/xmldom@~0.8.4
(dist-tag latest
) or @xmldom/xmldom@>=0.9.0-beta.4
(dist-tag next
).
One of the following approaches might help, depending on your use case:
documentElement
.childNode
.If you have any questions or comments about this advisory: