Version Details and Security Vulnerabilities

Affected versions of request will disclose local system memory to remote systems in certain circumstances. When a multipart request is made, and the type of body is number, then a buffer of that size will be allocated and sent to the remote server as the body.

Proof of Concept

var request = require('request');
var http = require('http');

var serveFunction = function (req, res){
	req.on('data', function (data) {
            console.log(data)
        });
	res.end();
};
var server = http.createServer(serveFunction);
server.listen(8000);

request({
	method: "POST",
	uri: 'http://localhost:8000',
	multipart: [{body:500}]
},function(err,res,body){});

Recommendation

Update to version 2.68.0 or later

The request package through 2.88.2 for Node.js and the @cypress/request package prior to 3.0.0 allow a bypass of SSRF mitigations via an attacker-controller server that does a cross-protocol redirect (HTTP to HTTPS, or HTTPS to HTTP).

NOTE: The request package is no longer supported by the maintainer.

A buffer over-read vulnerability exists in bl <4.0.3, <3.0.1, <2.2.1, and <1.2.3 which could allow an attacker to supply user input (even typed) that if it ends up in consume() argument and can become negative, the BufferList state can be corrupted, tricking it into exposing uninitialized memory via regular .slice() calls.

Hawk is an HTTP authentication scheme providing mechanisms for making authenticated HTTP requests with partial cryptographic verification of the request and response, covering the HTTP method, request URI, host, and optionally the request payload. Hawk used a regular expression to parse Host HTTP header (Hawk.utils.parseHost()), which was subject to regular expression DoS attack - meaning each added character in the attacker's input increases the computation time exponentially. parseHost() was patched in 9.0.1 to use built-in URL class to parse hostname instead.Hawk.authenticate() accepts options argument. If that contains host and port, those would be used instead of a call to utils.parseHost().

Versions of hawk prior to 3.1.3, or 4.x prior to 4.1.1 are affected by a regular expression denial of service vulnerability related to excessively long headers and URI's.

Recommendation

Update to hawk version 4.1.1 or later.

hoek versions prior to 8.5.1, and 9.x prior to 9.0.3 are vulnerable to prototype pollution in the clone function. If an object with the proto key is passed to clone() the key is converted to a prototype. This issue has been patched in version 9.0.3, and backported to 8.5.1.

Versions of hoek prior to 4.2.1 and 5.0.3 are vulnerable to prototype pollution.

The merge function, and the applyToDefaults and applyToDefaultsWithShallow functions which leverage merge behind the scenes, are vulnerable to a prototype pollution attack when provided an unvalidated payload created from a JSON string containing the __proto__ property.

This can be demonstrated like so:

var Hoek = require('hoek');
var malicious_payload = '{"__proto__":{"oops":"It works !"}}';

var a = {};
console.log("Before : " + a.oops);
Hoek.merge({}, JSON.parse(malicious_payload));
console.log("After : " + a.oops);

This type of attack can be used to overwrite existing properties causing a potential denial of service.

Recommendation

Update to version 4.2.1, 5.0.3 or later.

Summary

form-data uses Math.random() to select a boundary value for multipart form-encoded data. This can lead to a security issue if an attacker:

1. can observe other values produced by Math.random in the target application, and
2. can control one field of a request made using form-data

Because the values of Math.random() are pseudo-random and predictable (see: https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f), an attacker who can observe a few sequential values can determine the state of the PRNG and predict future values, includes those used to generate form-data's boundary value. The allows the attacker to craft a value that contains a boundary value, allowing them to inject additional parameters into the request.

This is largely the same vulnerability as was recently found in undici by parrot409 -- I'm not affiliated with that researcher but want to give credit where credit is due! My PoC is largely based on their work.

Details

The culprit is this line here: https://github.com/form-data/form-data/blob/426ba9ac440f95d1998dac9a5cd8d738043b048f/lib/form_data.js#L347

An attacker who is able to predict the output of Math.random() can predict this boundary value, and craft a payload that contains the boundary value, followed by another, fully attacker-controlled field. This is roughly equivalent to any sort of improper escaping vulnerability, with the caveat that the attacker must find a way to observe other Math.random() values generated by the application to solve for the state of the PRNG. However, Math.random() is used in all sorts of places that might be visible to an attacker (including by form-data itself, if the attacker can arrange for the vulnerable application to make a request to an attacker-controlled server using form-data, such as a user-controlled webhook -- the attacker could observe the boundary values from those requests to observe the Math.random() outputs). A common example would be a x-request-id header added by the server. These sorts of headers are often used for distributed tracing, to correlate errors across the frontend and backend. Math.random() is a fine place to get these sorts of IDs (in fact, opentelemetry uses Math.random for this purpose)

PoC

PoC here: https://github.com/benweissmann/CVE-2025-7783-poc

Instructions are in that repo. It's based on the PoC from https://hackerone.com/reports/2913312 but simplified somewhat; the vulnerable application has a more direct side-channel from which to observe Math.random() values (a separate endpoint that happens to include a randomly-generated request ID).

Impact

For an application to be vulnerable, it must:

• Use form-data to send data including user-controlled data to some other system. The attacker must be able to do something malicious by adding extra parameters (that were not intended to be user-controlled) to this request. Depending on the target system's handling of repeated parameters, the attacker might be able to overwrite values in addition to appending values (some multipart form handlers deal with repeats by overwriting values instead of representing them as an array)
• Reveal values of Math.random(). It's easiest if the attacker can observe multiple sequential values, but more complex math could recover the PRNG state to some degree of confidence with non-sequential values.

If an application is vulnerable, this allows an attacker to make arbitrary requests to internal systems.

Affected versions of mime are vulnerable to regular expression denial of service when a mime lookup is performed on untrusted user input.

Recommendation

Update to version 2.0.3 or later.

Versions of tunnel-agent before 0.6.0 are vulnerable to memory exposure.

This is exploitable if user supplied input is provided to the auth value and is a number.

Proof-of-concept:

require('request')({
  method: 'GET',
  uri: 'http://www.example.com',
  tunnel: true,
  proxy:{
    protocol: 'http:',
    host:'127.0.0.1',
    port:8080,
    auth:USERSUPPLIEDINPUT // number
  }
});

Recommendation

Update to version 0.6.0 or later.

The package postcss versions before 7.0.36 or between 8.0.0 and 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=(.*)

PoC

var postcss = require("postcss")
function build_attack(n) {
    var ret = "a{}"
    for (var i = 0; i < n; i++) {
        ret += "/*# sourceMappingURL="
    }
    return ret + "!";
}

postcss.parse('a{}/*# sourceMappingURL=a.css.map */') for (var i = 1; i <= 500000; i++) {
    if (i % 1000 == 0) {
        var time = Date.now();
        var attack_str = build_attack(i) try {
            postcss.parse(attack_str) var time_cost = Date.now() - time;
            console.log("attack_str.length: " + attack_str.length + ": " + time_cost + " ms");
        } catch (e) {
            var time_cost = Date.now() - time;
            console.log("attack_str.length: " + attack_str.length + ": " + time_cost + " ms");
        }
    }
}

An issue was discovered in PostCSS before 8.4.31. It affects linters using PostCSS to parse external Cascading Style Sheets (CSS). There may be \r discrepancies, as demonstrated by @font-face{ font:(\r/*);} in a rule.

This vulnerability affects linters using PostCSS to parse external untrusted CSS. An attacker can prepare CSS in such a way that it will contains parts parsed by PostCSS as a CSS comment. After processing by PostCSS, it will be included in the PostCSS output in CSS nodes (rules, properties) despite being originally included in a comment.

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.

A vulnerability was discovered in IS-SVG version 4.3.1 and below where a Regular Expression Denial of Service (ReDOS) occurs if the application is provided and checks a crafted invalid SVG string.

A vulnerability was found in diff before v3.5.0, the affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) attacks.

The NPM package micromatch prior to version 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in micromatch.braces() in index.js because the pattern .* will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persisted prior to https://github.com/micromatch/micromatch/pull/266. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching.

A vulnerability was found in Braces versions prior to 2.3.1. Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) attacks.

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.

The NPM package braces fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In lib/parse.js, if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.

fsevents before 1.2.11 depends on the https://fsevents-binaries.s3-us-west-2.amazonaws.com URL, which might allow an adversary to execute arbitrary code if any JavaScript project (that depends on fsevents) distributes code that was obtained from that URL at a time when it was controlled by an adversary.

xml2js versions before 0.5.0 allows an external attacker to edit or add new properties to an object. This is possible because the application does not properly validate incoming JSON keys, thus allowing the __proto__ property to be edited.

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.

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.

Recommendation

Upgrade to version 3.3.5 or higher.

Prototype pollution vulnerability in dot-prop npm package versions before 4.2.1 and versions 5.x before 5.1.1 allows an attacker to add arbitrary properties to JavaScript language constructs such as objects.

A flaw was found in http-proxy-agent, prior to version 2.1.0. It was discovered http-proxy-agent passes an auth option to the Buffer constructor without proper sanitization. This could result in a Denial of Service through the usage of all available CPU resources and data exposure through an uninitialized memory leak in setups where an attacker could submit typed input to the auth parameter.

Versions of http-proxy-agent before 2.1.0 are vulnerable to denial of service and uninitialized memory leak when unsanitized options are passed to Buffer. An attacker may leverage these unsanitized options to consume system resources.

Recommendation

Update to version 2.1.0 or later.

Versions of https-proxy-agent before 2.2.0 are vulnerable to denial of service. This is due to unsanitized options (proxy.auth) being passed to Buffer().

Recommendation

Update to version 2.2.0 or later.

Versions of https-proxy-agent prior to 2.2.3 are vulnerable to Machine-In-The-Middle. The package fails to enforce TLS on the socket if the proxy server responds the to the request with a HTTP status different than 200. This allows an attacker with access to the proxy server to intercept unencrypted communications, which may include sensitive information such as credentials.

Recommendation

Upgrade to version 3.0.0 or 2.2.3.

loadAsync in JSZip before 3.8.0 allows Directory Traversal via a crafted ZIP archive.

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.

Impact

body-parser <1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service.

Patches

this issue is patched in 1.20.3

References

Impact

In express <4.20.0, passing untrusted user input - even after sanitizing it - to response.redirect() may execute untrusted code

Patches

this issue is patched in express 4.20.0

Workarounds

users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist

Details

successful exploitation of this vector requires the following:

1. The attacker MUST control the input to response.redirect()
2. express MUST NOT redirect before the template appears
3. the browser MUST NOT complete redirection before:
4. the user MUST click on the link in the template

Impact

Versions of Express.js prior to 4.19.2 and pre-release alpha and beta versions before 5.0.0-beta.3 are affected by an open redirect vulnerability using malformed URLs.

When a user of Express performs a redirect using a user-provided URL Express performs an encode using encodeurl on the contents before passing it to the location header. This can cause malformed URLs to be evaluated in unexpected ways by common redirect allow list implementations in Express applications, leading to an Open Redirect via bypass of a properly implemented allow list.

The main method impacted is res.location() but this is also called from within res.redirect().

Patches

https://github.com/expressjs/express/commit/0867302ddbde0e9463d0564fea5861feb708c2dd https://github.com/expressjs/express/commit/0b746953c4bd8e377123527db11f9cd866e39f94

An initial fix went out with express@4.19.0, we then patched a feature regression in 4.19.1 and added improved handling for the bypass in 4.19.2.

Workarounds

The fix for this involves pre-parsing the url string with either require('node:url').parse or new URL. These are steps you can take on your own before passing the user input string to res.location or res.redirect.

References

https://github.com/expressjs/express/pull/5539 https://github.com/koajs/koa/issues/1800 https://expressjs.com/en/4x/api.html#res.location

Impact

passing untrusted user input - even after sanitizing it - to SendStream.redirect() may execute untrusted code

Patches

this issue is patched in send 0.19.0

Workarounds

users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist

Details

successful exploitation of this vector requires the following:

1. The attacker MUST control the input to response.redirect()
2. express MUST NOT redirect before the template appears
3. the browser MUST NOT complete redirection before:
4. the user MUST click on the link in the template

Impact

The cookie name could be used to set other fields of the cookie, resulting in an unexpected cookie value. For example, serialize("userName=<script>alert('XSS3')</script>; Max-Age=2592000; a", value) would result in "userName=<script>alert('XSS3')</script>; Max-Age=2592000; a=test", setting userName cookie to <script> and ignoring value.

A similar escape can be used for path and domain, which could be abused to alter other fields of the cookie.

Patches

Upgrade to 0.7.0, which updates the validation for name, path, and domain.

Workarounds

Avoid passing untrusted or arbitrary values for these fields, ensure they are set by the application instead of user input.

References

• https://github.com/jshttp/cookie/pull/167

Impact

passing untrusted user input - even after sanitizing it - to redirect() may execute untrusted code

Patches

this issue is patched in serve-static 1.16.0

Workarounds

users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist

Details

successful exploitation of this vector requires the following:

1. The attacker MUST control the input to response.redirect()
2. express MUST NOT redirect before the template appears
3. the browser MUST NOT complete redirection before:
4. the user MUST click on the link in the template

Impact

A bad regular expression is generated any time you have two parameters within a single segment, separated by something that is not a period (.). For example, /:a-:b.

Patches

For users of 0.1, upgrade to 0.1.10. All other users should upgrade to 8.0.0.

These versions add backtrack protection when a custom regex pattern is not provided:

• 0.1.10
• 1.9.0
• 3.3.0
• 6.3.0

They do not protect against vulnerable user supplied capture groups. Protecting against explicit user patterns is out of scope for old versions and not considered a vulnerability.

Version 7.1.0 can enable strict: true and get an error when the regular expression might be bad.

Version 8.0.0 removes the features that can cause a ReDoS.

Workarounds

All versions can be patched by providing a custom regular expression for parameters after the first in a single segment. As long as the custom regular expression does not match the text before the parameter, you will be safe. For example, change /:a-:b to /:a-:b([^-/]+).

If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length. For example, halving the attack string improves performance by 4x faster.

Details

Using /:a-:b will produce the regular expression /^\/([^\/]+?)-([^\/]+?)\/?$/. This can be exploited by a path such as /a${'-a'.repeat(8_000)}/a. OWASP has a good example of why this occurs, but the TL;DR is the /a at the end ensures this route would never match but due to naive backtracking it will still attempt every combination of the :a-:b on the repeated 8,000 -a.

Because JavaScript is single threaded and regex matching runs on the main thread, poor performance will block the event loop and can lead to a DoS. In local benchmarks, exploiting the unsafe regex will result in performance that is over 1000x worse than the safe regex. In a more realistic environment using Express v4 and 10 concurrent connections, this translated to average latency of ~600ms vs 1ms.

References

• OWASP
• Detailed blog post

Impact

The regular expression that is vulnerable to backtracking can be generated in versions before 0.1.12 of path-to-regexp, originally reported in CVE-2024-45296

Patches

Upgrade to 0.1.12.

Workarounds

Avoid using two parameters within a single path segment, when the separator is not . (e.g. no /:a-:b). Alternatively, you can define the regex used for both parameters and ensure they do not overlap to allow backtracking.

References

• https://github.com/advisories/GHSA-9wv6-86v2-598j
• https://blakeembrey.com/posts/2024-09-web-redos/

Impact

Using Babel to compile code that was specifically crafted by an attacker can lead to arbitrary code execution during compilation, when using plugins that rely on the path.evaluate()or path.evaluateTruthy() internal Babel methods.

Known affected plugins are:

• @babel/plugin-transform-runtime
• @babel/preset-env when using its useBuiltIns option
• Any "polyfill provider" plugin that depends on @babel/helper-define-polyfill-provider, such as babel-plugin-polyfill-corejs3, babel-plugin-polyfill-corejs2, babel-plugin-polyfill-es-shims, babel-plugin-polyfill-regenerator

No other plugins under the @babel/ namespace are impacted, but third-party plugins might be.

Users that only compile trusted code are not impacted.

Patches

The vulnerability has been fixed in @babel/traverse@7.23.2.

Babel 6 does not receive security fixes anymore (see Babel's security policy), hence there is no patch planned for babel-traverse@6.

Workarounds

• Upgrade @babel/traverse to v7.23.2 or higher. You can do this by deleting it from your package manager's lockfile and re-installing the dependencies. @babel/core >=7.23.2 will automatically pull in a non-vulnerable version.
• If you cannot upgrade @babel/traverse and are using one of the affected packages mentioned above, upgrade them to their latest version to avoid triggering the vulnerable code path in affected @babel/traverse versions:
  • @babel/plugin-transform-runtime v7.23.2
  • @babel/preset-env v7.23.2
  • @babel/helper-define-polyfill-provider v0.4.3
  • babel-plugin-polyfill-corejs2 v0.4.6
  • babel-plugin-polyfill-corejs3 v0.8.5
  • babel-plugin-polyfill-es-shims v0.10.0
  • babel-plugin-polyfill-regenerator v0.5.3

The shell-quote package before 1.7.3 for Node.js allows command injection. An attacker can inject unescaped shell metacharacters through a regex designed to support Windows drive letters. If the output of this package is passed to a real shell as a quoted argument to a command with exec(), an attacker can inject arbitrary commands. This is because the Windows drive letter regex character class is [A-z] instead of the correct [A-Za-z]. Several shell metacharacters exist in the space between capital letter Z and lower case letter a, such as the backtick character.

Impact

A request with a number of headers exceeding theserver.maxHeadersCount threshold could be used to crash a ws server.

Proof of concept

const http = require('http');
const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 0 }, function () {
  const chars = "!#$%&'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~".split('');
  const headers = {};
  let count = 0;

  for (let i = 0; i < chars.length; i++) {
    if (count === 2000) break;

    for (let j = 0; j < chars.length; j++) {
      const key = chars[i] + chars[j];
      headers[key] = 'x';

      if (++count === 2000) break;
    }
  }

  headers.Connection = 'Upgrade';
  headers.Upgrade = 'websocket';
  headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ==';
  headers['Sec-WebSocket-Version'] = '13';

  const request = http.request({
    headers: headers,
    host: '127.0.0.1',
    port: wss.address().port
  });

  request.end();
});

Patches

The vulnerability was fixed in ws@8.17.1 (https://github.com/websockets/ws/commit/e55e5106f10fcbaac37cfa89759e4cc0d073a52c) and backported to ws@7.5.10 (https://github.com/websockets/ws/commit/22c28763234aa75a7e1b76f5c01c181260d7917f), ws@6.2.3 (https://github.com/websockets/ws/commit/eeb76d313e2a00dd5247ca3597bba7877d064a63), and ws@5.2.4 (https://github.com/websockets/ws/commit/4abd8f6de4b0b65ef80b3ff081989479ed93377e)

Workarounds

In vulnerable versions of ws, the issue can be mitigated in the following ways:

1. Reduce the maximum allowed length of the request headers using the --max-http-header-size=size and/or the maxHeaderSize options so that no more headers than the server.maxHeadersCount limit can be sent.
2. Set server.maxHeadersCount to 0 so that no limit is applied.

Credits

The vulnerability was reported by Ryan LaPointe in https://github.com/websockets/ws/issues/2230.

References

• https://github.com/websockets/ws/issues/2230
• https://github.com/websockets/ws/pull/2231

Affected versions of ws can crash when a specially crafted Sec-WebSocket-Extensions header containing Object.prototype property names as extension or parameter names is sent.

Proof of concept

const WebSocket = require('ws');
const net = require('net');

const wss = new WebSocket.Server({ port: 3000 }, function () {
  const payload = 'constructor';  // or ',;constructor'

  const request = [
    'GET / HTTP/1.1',
    'Connection: Upgrade',
    'Sec-WebSocket-Key: test',
    'Sec-WebSocket-Version: 8',
    `Sec-WebSocket-Extensions: ${payload}`,
    'Upgrade: websocket',
    '\r\n'
  ].join('\r\n');

  const socket = net.connect(3000, function () {
    socket.resume();
    socket.write(request);
  });
});

Recommendation

Update to version 3.3.1 or later.

An issue in parse-git-config v.3.0.0 allows an attacker to obtain sensitive information via the expandKeys function.

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.

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

Prototype pollution vulnerability in function parseQuery in parseQuery.js in webpack loader-utils prior to version 2.0.3 via the name variable in parseQuery.js.

The parse method of the JSON5 library before and including version 2.2.1 does not restrict parsing of keys named __proto__, allowing specially crafted strings to pollute the prototype of the resulting object.

This vulnerability pollutes the prototype of the object returned by JSON5.parse and not the global Object prototype, which is the commonly understood definition of Prototype Pollution. However, polluting the prototype of a single object can have significant security impact for an application if the object is later used in trusted operations.

Impact

This vulnerability could allow an attacker to set arbitrary and unexpected keys on the object returned from JSON5.parse. The actual impact will depend on how applications utilize the returned object and how they filter unwanted keys, but could include denial of service, cross-site scripting, elevation of privilege, and in extreme cases, remote code execution.

Mitigation

This vulnerability is patched in json5 v2.2.2 and later. A patch has also been backported for json5 v1 in versions v1.0.2 and later.

Details

Suppose a developer wants to allow users and admins to perform some risky operation, but they want to restrict what non-admins can do. To accomplish this, they accept a JSON blob from the user, parse it using JSON5.parse, confirm that the provided data does not set some sensitive keys, and then performs the risky operation using the validated data:

const JSON5 = require('json5');

const doSomethingDangerous = (props) => {
  if (props.isAdmin) {
    console.log('Doing dangerous thing as admin.');
  } else {
    console.log('Doing dangerous thing as user.');
  }
};

const secCheckKeysSet = (obj, searchKeys) => {
  let searchKeyFound = false;
  Object.keys(obj).forEach((key) => {
    if (searchKeys.indexOf(key) > -1) {
      searchKeyFound = true;
    }
  });
  return searchKeyFound;
};

const props = JSON5.parse('{"foo": "bar"}');
if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) {
  doSomethingDangerous(props); // "Doing dangerous thing as user."
} else {
  throw new Error('Forbidden...');
}

If the user attempts to set the isAdmin key, their request will be rejected:

const props = JSON5.parse('{"foo": "bar", "isAdmin": true}');
if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) {
  doSomethingDangerous(props);
} else {
  throw new Error('Forbidden...'); // Error: Forbidden...
}

However, users can instead set the __proto__ key to {"isAdmin": true}. JSON5 will parse this key and will set the isAdmin key on the prototype of the returned object, allowing the user to bypass the security check and run their request as an admin:

const props = JSON5.parse('{"foo": "bar", "__proto__": {"isAdmin": true}}');
if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) {
  doSomethingDangerous(props); // "Doing dangerous thing as admin."
} else {
  throw new Error('Forbidden...');
}

shelljs is vulnerable to Improper Privilege Management

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

The got package before 11.8.5 and 12.1.0 for Node.js allows a redirect to a UNIX socket.

Versions of mem prior to 4.0.0 are vulnerable to Denial of Service (DoS). The package fails to remove old values from the cache even after a value passes its maxAge property. This may allow attackers to exhaust the system's memory if they are able to abuse the application logging.

Recommendation

Upgrade to version 4.0.0 or later.

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.

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.

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?

• https://marked.js.org/using_advanced#workers
• https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS

For more information

If you have any questions or comments about this advisory:

• Open an issue in marked

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.

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?

• https://marked.js.org/using_advanced#workers
• https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS

For more information

If you have any questions or comments about this advisory:

• Open an issue in marked

Versions of marked from 0.3.14 until 0.6.2 are vulnerable to Regular Expression Denial of Service. Email addresses may be evaluated in quadratic time, allowing attackers to potentially crash the node process due to resource exhaustion.

Recommendation

Upgrade to version 0.6.2 or later.

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. Exponential grammars (C, Perl, JavaScript) are auto-registered when using the common grammar subset/library require('highlight.js/lib/common') as of 10.4.0 - see https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@10.4.0/build/highlight.js

All versions prior to 10.4.1 are vulnerable, including version 9.18.5.

Grammars with exponential backtracking issues:

• c-like (c, cpp, arduino)
• handlebars (htmlbars)
• gams
• perl
• jboss-cli
• r
• erlang-repl
• powershell
• routeros
• livescript (10.4.0 and 9.18.5 included this fix)
• javascript & typescript (10.4.0 included partial fixes)

And of course any aliases of those languages have the same issue. ie: hpp is no safer than cpp.

Grammars with polynomial backtracking issues:

• kotlin
• gcode
• d
• aspectj
• moonscript
• coffeescript/livescript
• csharp
• scilab
• crystal
• elixir
• basic
• ebnf
• ruby
• fortran/irpf90
• livecodeserver
• yaml
• x86asm
• dsconfig
• markdown
• ruleslanguage
• xquery
• sqf

And again: any aliases of those languages have the same issue. ie: ruby and rb share the same ruby issues.

Patches

• Version 10.4.1 resolves these vulnerabilities. Please upgrade.

Workarounds / Mitigations

• Discontinue use the affected grammars. (or perhaps use only those with poly vs exponential issues)
• Attempt cherry-picking the grammar fixes into older versions...
• Attempt using newer CDN versions of any affected languages. (ie using an older CDN version of the library with newer CDN grammars). Your mileage may vary.

References

• https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS

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