Next.js 12.0.2, released shortly after 12.0.1, offers incremental improvements and bug fixes over the previous stable version. While the core functionality remains consistent, developers should be aware of key updates in dependencies. Both versions share the same core architecture as a React Framework designed to build modern web applications and feature server-side rendering, static site generation, and client-side routing out of the box.
A noticeable difference lies in the @next/env and @next/polyfill-module dependencies, which have been updated to version 12.0.2, aligning with the main package version. Furthermore, several @next/swc related optional dependencies targeted to specific architectures like darwin, android, linux and windows saw version upgrades from 12.0.1 to 12.0.2 in the newer release.
However, @next/swc-linux-x64-musl stays at version 12.0.1 for the new version. Another key distinction is the update of webpack5 from version 5.60.0 to 5.61.0. This jump might include performance optimizations or bug fixes within the webpack build process for Next.js applications. Developers employing Next.js should examine the webpack changelog for comprehensive details on these changes. Finally, the number of files and the unpacked size grew a bit from 1236 files to 1243 files and from 28986828 bytes to 29064528 meaning that there have been some added functionalities or libraries.
All the vulnerabilities related to the version 12.0.2 of the package
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.
Denial of Service Vulnerability in next.js
Vulnerable code could allow a bad actor to trigger a denial of service attack for anyone running a Next.js app at version >= 12.0.0, and using i18n functionality.
A patch has been released, next@12.0.9, that mitigates this issue. We recommend all affected users upgrade as soon as possible.
We recommend upgrading whether you can reproduce or not although you can ensure /${locale}/_next/ is blocked from reaching the Next.js instance until you upgrade.
If you have any questions or comments about this advisory:
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',
},
}
Authorization Bypass in Next.js Middleware
It is possible to bypass authorization checks within a Next.js application, if the authorization check occurs in middleware.
15.2.314.2.2513.5.912.3.5Note: Next.js deployments hosted on Vercel are automatically protected against this vulnerability.
If patching to a safe version is infeasible, it is recommend that you prevent external user requests which contain the x-middleware-subrequest header from reaching your Next.js application.
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.
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.