Express.js saw a minor version bump from 4.12.2 to 4.12.3, primarily focusing on dependency updates and likely bug fixes or small enhancements. Developers upgrading should be aware of changes within the dependency tree. Notably, the 'qs' package jumped from version 2.3.3 to 2.4.1, potentially impacting query string parsing behavior. 'send' went from 0.12.1 to 0.12.2, likely involving improvements in static file serving. The 'debug' utility was updated from 2.1.1 to 2.1.3, suggesting enhanced debugging capabilities. 'accepts' also received a bump from ~1.2.4 to ~1.2.5, this could affect content negotiation. Finally the finalhandler package got an upgrade, impacting error handling.
On the development dependency side, 'mocha' moved from ~2.1.0 to ~2.2.1, which might affect testing scripts. Similarly, 'morgan' (request logger) was updated from ~1.5.1 to ~1.5.2 and 'should' (assertion library) from ~5.0.1 to ~5.2.0. 'body-parser' incremented from ~1.12.0 to ~1.12.2, 'express-session' from ~1.10.3 to ~1.10.4, and 'method-override' from ~2.3.1 to ~2.3.2, potentially altering request handling middleware. 'istanbul' also got an update, affecting the coverage reports for tests. The upgrade also suggests some attention to underlying mechanics in express as a whole. Developers relying on specific behaviors of these dependencies should review their respective changelogs for detailed information on the changes introduced.
All the vulnerabilities related to the version 4.12.3 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:
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.
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.
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.