Express 4.4.3 is a minor release update to the popular web development framework, building upon the foundation of version 4.4.2. Both versions maintain the core principles of providing a Sinatra-inspired, flexible routing and middleware system for Node.js applications. Examining the changes, one readily notices a dependency update within the dependencies section. Specifically, the send package has been bumped from version 0.4.2 to 0.4.3, and the debug package has been updated from 1.0.1 to 1.0.2. The serve-static package has been updated from 1.2.2 to 1.2.3, and the accepts package has been updated from 1.0.2 to 1.0.3. These updates generally indicate bug fixes, performance improvements, or security patches within those respective modules.
For developers, this means that upgrading to Express 4.4.3 potentially brings enhanced stability and security to their applications. While the changes may not introduce new features, they are essential for maintaining a healthy and up-to-date codebase. If you're relying on send, debug, serve-static or accepts packages directly, reviewing their individual changelogs is advisable to understand the specific nuances of these updates. Furthermore, if you indirectly depend on those packages through Express and discover bugs or performance issues, the upgrade to 4.4.3 might resolve the issues. Be sure to test your application after upgrading to confirm compatibility and ensure that no regressions are introduced. Both versions of Express utilize the MIT license, encourage open-source contributions, and depend upon a rich ecosystem of middleware and utilities readily available through npm.
All the vulnerabilities related to the version 4.4.3 of the package
No Charset in Content-Type Header in express
Vulnerable versions of express do not specify a charset field in the content-type header while displaying 400 level response messages. The lack of enforcing user's browser to set correct charset, could be leveraged by an attacker to perform a cross-site scripting attack, using non-standard encodings, like UTF-7.
For express 3.x, update express to version 3.11 or later. For express 4.x, update express to version 4.5 or later.
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:
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 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.
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.
cookie-signature Timing Attack
Affected versions of cookie-signature are vulnerable to timing attacks as a result of using a fail-early comparison instead of a constant-time comparison.
Timing attacks remove the exponential increase in entropy gained from increased secret length, by providing per-character feedback on the correctness of a guess via miniscule timing differences.
Under favorable network conditions, an attacker can exploit this to guess the secret in no more than charset*length guesses, instead of charset^length guesses required were the timing attack not present.
Update to 1.0.4 or later.