Next.js version 10.2.2 represents a minor update following the 10.2.1 release, focusing on incremental improvements and bug fixes within the React framework. Examining the dependencies, the key differentiating factor lies in the @next scoped packages. In the newer 10.2.2 version, @next/env, @next/polyfill-module, @next/react-dev-overlay, and @next/react-refresh-utils are all updated to version 10.2.2, indicating internal refinements related to environment configuration, polyfilling, development overlay features, and React Fast Refresh integration. These changes likely contribute to a smoother and more efficient development experience, particularly concerning hot reloading and debugging.
Furthermore, while both versions share a vast number of identical dependencies and devDependencies, a noteworthy change appears in postcss-loader. Version 10.2.1 uses postcss-loader version 4.0.3, whereas 10.2.2 upgrades this to version 4.3.0. This implies an update to the PostCSS integration used for styling, potentially bringing bug fixes, performance enhancements, or new features related to CSS processing.
These specific differences suggest that upgrading from 10.2.1 to 10.2.2 will primarily benefit developers by providing subtle refinements in critical areas like development experience, internal Next.js utilities, and CSS handling. While the core functionality remains consistent, the upgraded dependencies indicate a focus on stability and incremental improvements. Developers should consider upgrading to leverage these enhancements for a potentially more robust and efficient workflow.
All the vulnerabilities related to the version 10.2.2 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
XSS in Image Optimization API for Next.js
next.config.js file has images.domains array assignedimages.domains allows user-provided SVGnext.config.js file has images.loader assigned to something other than defaultUnexpected 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.
Improper CSP in Image Optimization API for Next.js versions between 10.0.0 and 12.1.0
Next.js is a React framework. Starting with version 10.0.0 and prior to version 12.1.0, Next.js is vulnerable to User Interface (UI) Misrepresentation of Critical Information. In order to be affected, the next.config.js file must have an images.domains array assigned and the image host assigned in images.domains must allow user-provided SVG. If the next.config.js file has images.loader assigned to something other than default, the instance is not affected. Version 12.1.0 contains a patch for this issue. As a workaround, change next.config.js to use a different loader configuration other than the default.
next.config.js file has images.domains array assignednext.config.js file has images.loader assigned to something other than defaultChange next.config.js to use a different loader configuration other than the default, for example:
module.exports = {
images: {
loader: 'imgix',
path: 'https://example.com/myaccount/',
},
}
Or if you want to use the loader prop on the component, you can use custom:
module.exports = {
images: {
loader: 'custom',
},
}
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.
Denial of Service condition in Next.js image optimization
The image optimization feature of Next.js contained a vulnerability which allowed for a potential Denial of Service (DoS) condition which could lead to excessive CPU consumption.
Not affected:
next.config.js file is configured with images.unoptimized set to true or images.loader set to a non-default value.This issue was fully patched in Next.js 14.2.7. We recommend that users upgrade to at least this version.
Ensure that the next.config.js file has either images.unoptimized, images.loader or images.loaderFile assigned.
Brandon Dahler (brandondahler), AWS Dimitrios Vlastaras
Next.js authorization bypass vulnerability
If a Next.js application is performing authorization in middleware based on pathname, it was possible for this authorization to be bypassed.
This issue was patched in Next.js 14.2.15 and later.
If your Next.js application is hosted on Vercel, this vulnerability has been automatically mitigated, regardless of Next.js version.
There are no official workarounds for this vulnerability.
We'd like to thank tyage (GMO CyberSecurity by IERAE) for responsible disclosure of this issue.
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
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.
node-fetch forwards secure headers to untrusted sites
node-fetch forwards secure headers such as authorization, www-authenticate, cookie, & cookie2 when redirecting to a untrusted site.
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.
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.