Next.js version 12.0.6 introduces subtle yet important updates compared to the previous stable version 12.0.5. The core framework description remains consistent, emphasizing its role as "The React Framework." One of the primary changes involves updating the internal @next/swc packages, which are crucial for compilation and transformation. These include architecture-specific binaries like @next/swc-darwin-x64, @next/swc-darwin-arm64, and others targeting various operating systems and architectures. These upgrades likely include performance improvements and bug fixes within the SWC compiler. Apart from the @next/swc package version changes, there's also an update to @next/env and @next/polyfill-module and @next/react-dev-overlayand @next/react-refresh-utils. While most dependencies remain the same, developers should note these internal version bumps within the Next.js ecosystem. The dist metadata also reflects a slight difference in unpackedSize, suggesting minor adjustments in the bundled files. The release date indicates a quick follow-up release, potentially to address issues found in 12.0.5. For developers, this release likely provides incremental improvements and stability enhancements, particularly for those leveraging the latest JavaScript features and targeting diverse deployment environments. If you experienced any problem when running next 12.0.5, you should update to this version.
All the vulnerabilities related to the version 12.0.6 of the package
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.