Next.js version 12.1.6 brings incremental improvements to the popular React framework, building upon the solid foundation of 12.1.5. One notable change is the updated caniuse-lite dependency, moving from version ^1.0.30001283 to ^1.0.30001332, ensuring better browser compatibility data. It also includes the library @types/styled-jsx removed from dependencies. Core dependencies like @next/swc (the Rust-based compiler) are bumped across all supported platforms (Darwin, Android, Linux, and Windows), indicating potential performance enhancements and bug fixes in the compilation process. These @next/swc updates are also reflected in the optional dependencies section, which allows the installer to choose the correct binary depending on the architecture.
While many developer dependencies remain consistent, crucial updates appear within the browserslist dependency, shifting from version 4.18.1 to 4.20.2. This ensures that Next.js targets a more current set of browsers, providing a more modern and secure experience. There's also a notable update from postcss-scss version 3.0.5 to 4.0.3 reflecting updates in the PostCSS ecosystem. Furthermore, internal utilities like @next/polyfill-module, @next/polyfill-nomodule, and @next/react-dev-overlay see version bumps, indicating internal improvements. The release also introduces updates to type definitions, such as @types/webpack-sources1 which is now specified using npm alias @types/webpack-sources@0.1.5, likely addressing compatibility or typing issues. These changes collectively contribute to a more refined Next.js experience.
All the vulnerabilities related to the version 12.1.6 of the package
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.