All the vulnerabilities related to the version 0.1.1 of the package
Express.js Open Redirect in malformed URLs
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().
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.
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.
https://github.com/expressjs/express/pull/5539 https://github.com/koajs/koa/issues/1800 https://expressjs.com/en/4x/api.html#res.location
express vulnerable to XSS via response.redirect()
In express <4.20.0, passing untrusted user input - even after sanitizing it - to response.redirect() may execute untrusted code
this issue is patched in express 4.20.0
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
successful exploitation of this vector requires the following:
Denial-of-Service Extended Event Loop Blocking in qs
Versions prior to 1.0.0 of qs are affected by a denial of service vulnerability that results from excessive recursion in parsing a deeply nested JSON string.
Update to version 1.0.0 or later
Denial-of-Service Memory Exhaustion in qs
Versions prior to 1.0 of qs are affected by a denial of service condition. This condition is triggered by parsing a crafted string that deserializes into very large sparse arrays, resulting in the process running out of memory and eventually crashing.
Update to version 1.0.0 or later.
Prototype Pollution Protection Bypass in qs
Affected version of qs are vulnerable to Prototype Pollution because it is possible to bypass the protection. The qs.parse function fails to properly prevent an object's prototype to be altered when parsing arbitrary input. Input containing [ or ] may bypass the prototype pollution protection and alter the Object prototype. This allows attackers to override properties that will exist in all objects, which may lead to Denial of Service or Remote Code Execution in specific circumstances.
Upgrade to 6.0.4, 6.1.2, 6.2.3, 6.3.2 or later.
qs vulnerable to Prototype Pollution
qs before 6.10.3 allows attackers to cause a Node process hang because an __ proto__ key can be used. In many typical web framework use cases, an unauthenticated remote attacker can place the attack payload in the query string of the URL that is used to visit the application, such as a[__proto__]=b&a[__proto__]&a[length]=100000000. The fix was backported to qs 6.9.7, 6.8.3, 6.7.3, 6.6.1, 6.5.3, 6.4.1, 6.3.3, and 6.2.4.
Directory Traversal in send
Versions 0.8.3 and earlier of send are affected by a directory traversal vulnerability. When relying on the root option to restrict file access it may be possible for an application consumer to escape out of the restricted directory and access files in a similarly named directory.
For example, static(_dirname + '/public') would allow access to _dirname + '/public-restricted'.
Update to version 0.8.4 or later.
Root Path Disclosure in send
Versions of send prior to 0.11.2 are affected by an information leakage vulnerability which may allow an attacker to enumerate paths on the server filesystem.
Update to version 0.11.1 or later.
send vulnerable to template injection that can lead to XSS
passing untrusted user input - even after sanitizing it - to SendStream.redirect() may execute untrusted code
this issue is patched in send 0.19.0
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
successful exploitation of this vector requires the following:
Regular Expression Denial of Service in ms
Versions of ms prior to 0.7.1 are affected by a regular expression denial of service vulnerability when extremely long version strings are parsed.
var ms = require('ms');
var genstr = function (len, chr) {
var result = "";
for (i=0; i<=len; i++) {
result = result + chr;
}
return result;
}
ms(genstr(process.argv[2], "5") + " minutea");
Showing increase in execution time based on the input string.
$ time node ms.js 10000
real 0m0.758s
user 0m0.724s
sys 0m0.031s
$ time node ms.js 20000
real 0m2.580s
user 0m2.494s
sys 0m0.047s
$ time node ms.js 30000
real 0m5.747s
user 0m5.483s
sys 0m0.080s
$ time node ms.js 80000
real 0m41.022s
user 0m38.894s
sys 0m0.529s
Vercel ms Inefficient Regular Expression Complexity vulnerability
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.
mime Regular Expression Denial of Service when MIME lookup performed on untrusted user input
Affected versions of mime are vulnerable to regular expression denial of service when a mime lookup is performed on untrusted user input.
Update to version 2.0.3 or later.
debug Inefficient Regular Expression Complexity vulnerability
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.
Regular Expression Denial of Service in debug
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.
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.
Regular Expression Denial of Service in fresh
Affected versions of fresh are vulnerable to regular expression denial of service when parsing specially crafted user input.
Update to version 0.5.2 or later.
cookie accepts cookie name, path, and domain with out of bounds characters
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.
Upgrade to 0.7.0, which updates the validation for name, path, and domain.
Avoid passing untrusted or arbitrary values for these fields, ensure they are set by the application instead of user input.
Regular Expression Denial of Service in negotiator
Affected versions of negotiator are vulnerable to regular expression denial of service attacks, which trigger upon parsing a specially crafted Accept-Language header value.
Update to version 0.6.1 or later.
Open Redirect in serve-static
Versions of serve-static prior to 1.6.5 ( or 1.7.x prior to 1.7.2 ) are affected by an open redirect vulnerability on some browsers when configured to mount at the root directory.
A link to http://example.com//www.google.com/%2e%2e will redirect to //www.google.com/%2e%2e
Some browsers will interpret this as http://www.google.com/%2e%2e, resulting in an external redirect.
Version 1.7.x: Update to version 1.7.2 or later. Version 1.6.x: Update to version 1.6.5 or later.
serve-static vulnerable to template injection that can lead to XSS
passing untrusted user input - even after sanitizing it - to redirect() may execute untrusted code
this issue is patched in serve-static 1.16.0
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
successful exploitation of this vector requires the following:
path-to-regexp outputs backtracking regular expressions
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.
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:
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.
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.
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.
path-to-regexp contains a ReDoS
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
Upgrade to 0.1.12.
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.
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.
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.
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.
Remote Memory Exposure in request
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.
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){});
Update to version 2.68.0 or later
Server-Side Request Forgery in Request
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.
Regular Expression Denial of Service in hawk
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.
Update to hawk version 4.1.1 or later.
Uncontrolled Resource Consumption in Hawk
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().
Prototype Pollution in hoek
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.
Update to version 4.2.1, 5.0.3 or later.
hoek subject to prototype pollution via the clone function.
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.
form-data uses unsafe random function in form-data for choosing boundary
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:
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.
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 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).
For an application to be vulnerable, it must:
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)If an application is vulnerable, this allows an attacker to make arbitrary requests to internal systems.
Memory Exposure in tunnel-agent
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
}
});
Update to version 0.6.0 or later.