All the vulnerabilities related to the version 0.2.3 of the package
Uncontrolled Resource Consumption in trim-newlines
@rkesters/gnuplot is an easy to use node module to draw charts using gnuplot and ps2pdf. 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.
Command Injection in lodash
lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function.
Command Injection in lodash
lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function.
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.
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.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.
Denial of Service in js-yaml
Versions of js-yaml prior to 3.13.0 are vulnerable to Denial of Service. By parsing a carefully-crafted YAML file, the node process stalls and may exhaust system resources leading to a Denial of Service.
Upgrade to version 3.13.0.
Code Injection in js-yaml
Versions of js-yaml prior to 3.13.1 are vulnerable to Code Injection. The load() function may execute arbitrary code injected through a malicious YAML file. Objects that have toString as key, JavaScript code as value and are used as explicit mapping keys allow attackers to execute the supplied code through the load() function. The safeLoad() function is unaffected.
An example payload is
{ toString: !<tag:yaml.org,2002:js/function> 'function (){return Date.now()}' } : 1
which returns the object
{
"1553107949161": 1
}
Upgrade to version 3.13.1.
js-yaml has prototype pollution in merge (<<)
In js-yaml 4.1.0, 4.0.0, and 3.14.1 and below, it's possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution (__proto__). All users who parse untrusted yaml documents may be impacted.
Problem is patched in js-yaml 4.1.1 and 3.14.2.
You can protect against this kind of attack on the server by using node --disable-proto=delete or deno (in Deno, pollution protection is on by default).
https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html
Arbitrary Code Execution in underscore
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.
Prototype pollution in getobject
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.
Prototype Pollution in highlight.js
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.
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.
Manually patch your library to create null objects for both languages and aliases:
const HLJS = function(hljs) {
// ...
var languages = Object.create(null);
var aliases = Object.create(null);
Filter the language names that users are allowed to inject into your HTML to guarantee they are valid.
If you have any questions or comments about this advisory:
Inefficient Regular Expression Complexity in marked
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.
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.
Has the problem been patched?
Yes
What versions should users upgrade to?
4.0.10
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.
Are there any links users can visit to find out more?
If you have any questions or comments about this advisory:
Marked vulnerable to XSS from data URIs
marked version 0.3.6 and earlier is vulnerable to an XSS attack in the data: URI parser.
Multiple Content Injection Vulnerabilities in marked
Versions 0.3.0 and earlier of marked are affected by two cross-site scripting vulnerabilities, even when sanitize: true is set.
The attack vectors for this vulnerability are GFM Codeblocks and JavaScript URLs.
Upgrade to version 0.3.1 or later.
VBScript Content Injection in marked
Versions 0.3.2 and earlier of marked are affected by a cross-site scripting vulnerability even when sanitize:true is set.
[xss link](vbscript:alert(1))
will get a link
<a href="vbscript:alert(1)">xss link</a>
Update to version 0.3.3 or later.
Regular Expression Denial of Service in marked
Versions 0.3.3 and earlier of marked are affected by a regular expression denial of service ( ReDoS ) vulnerability when passed inputs that reach the em inline rule.
Update to version 0.3.4 or later.
Marked allows Regular Expression Denial of Service (ReDoS) attacks
Marked prior to version 0.3.17 is vulnerable to a Regular Expression Denial of Service (ReDoS) attack due to catastrophic backtracking in several regular expressions used for parsing HTML tags and markdown links. An attacker can exploit this vulnerability by providing specially crafted markdown input, such as deeply nested or repetitively structured brackets or tag attributes, which cause the parser to hang and lead to a Denial of Service.
Inefficient Regular Expression Complexity in marked
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.
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.
Has the problem been patched?
Yes
What versions should users upgrade to?
4.0.10
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.
Are there any links users can visit to find out more?
If you have any questions or comments about this advisory:
Sanitization bypass using HTML Entities in marked
Affected versions of marked are susceptible to a cross-site scripting vulnerability in link components when sanitize:true is configured.
This flaw exists because link URIs containing HTML entities get processed in an abnormal manner. Any HTML Entities get parsed on a best-effort basis and included in the resulting link, while if that parsing fails that character is omitted.
For example:
A link URI such as
javascript֍ocument;alert(1)
Renders a valid link that when clicked will execute alert(1).
Update to version 0.3.6 or later.
Regular Expression Denial of Service in marked
Affected versions of marked are vulnerable to a regular expression denial of service.
The amplification in this vulnerability is significant, with 1,000 characters resulting in the event loop being blocked for around 6 seconds.
Update to version 0.3.9 or later.
Regular Expression Denial of Service in underscore.string
Versions of underscore.string prior to 3.3.5 are vulnerable to Regular Expression Denial of Service (ReDoS).
The function unescapeHTML is vulnerable to ReDoS due to an overly-broad regex. The slowdown is approximately 2s for 50,000 characters but grows exponentially with larger inputs.
Upgrade to version 3.3.5 or higher.
minimatch ReDoS vulnerability
A vulnerability was found in the minimatch package. This flaw allows a Regular Expression Denial of Service (ReDoS) when calling the braceExpand function with specific arguments, resulting in a Denial of Service.
Regular Expression Denial of Service in minimatch
Affected versions of minimatch are vulnerable to regular expression denial of service attacks when user input is passed into the pattern argument of minimatch(path, pattern).
var minimatch = require(“minimatch”);
// utility function for generating long strings
var genstr = function (len, chr) {
var result = “”;
for (i=0; i<=len; i++) {
result = result + chr;
}
return result;
}
var exploit = “[!” + genstr(1000000, “\\”) + “A”;
// minimatch exploit.
console.log(“starting minimatch”);
minimatch(“foo”, exploit);
console.log(“finishing minimatch”);
Update to version 3.0.2 or later.
Prototype Pollution
Prototype pollution vulnerability in ‘expand-hash’ versions 0.1.0 through 1.0.1 allows an attacker to cause a denial of service and may lead to remote code execution.
ini before 1.3.6 vulnerable to Prototype Pollution via ini.parse
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.
This has been patched in 1.3.6.
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