Next.js 13.4.7 is a minor release following version 13.4.6, both iterations of the popular React framework designed for building performant web applications. At their core, both versions share a similar architecture, leveraging dependencies such as Zod for data validation, Busboy for handling file uploads, and PostCSS for CSS transformations. They also maintain consistent peer dependencies for React, React DOM, and OpenTelemetry API, ensuring compatibility with established ecosystems.
Digging deeper uncovers subtle but crucial changes. While the core dependencies remain largely consistent, the @next/env and @next/swc dependencies are updated to reflect the specific version (13.4.7 in the newer release), indicating targeted improvements or bug fixes within Next.js's environment variables and SWC (Speedy Web Compiler) integration. This often translates to enhanced build times or improved runtime performance. A number of dev dependencies are affected like @next/polyfill-module, @next/polyfill-nomodule, @next/react-dev-overlay, @next/react-refresh-utils.
For developers, this incremental update signals a commitment to stability and continuous improvement. Upgrading from 13.4.6 to 13.4.7 likely addresses known issues and incorporates minor enhancements without introducing major breaking changes. Developers exploring server-side rendering (SSR), static site generation (SSG), or API routes should find both versions familiar, but migrating to 13.4.7 is advisable to benefit from the latest refinements and potential performance gains within the Next.js ecosystem and some bug fixes. The small number of file changes and the close release dates suggest the update is more bug fixes than architectural enhancements.
All the vulnerabilities related to the version 13.4.7 of the package
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 Denial of Service (DoS) condition
A Denial of Service (DoS) condition was identified in Next.js. Exploitation of the bug can trigger a crash, affecting the availability of the server.
This vulnerability can affect all Next.js deployments on the affected versions.
This vulnerability was resolved in Next.js 13.5 and later. We recommend that users upgrade to a safe version.
There are no official workarounds for this vulnerability.
Next.js Vulnerable to HTTP Request Smuggling
Inconsistent interpretation of a crafted HTTP request meant that requests are treated as both a single request, and two separate requests by Next.js, leading to desynchronized responses. This led to a response queue poisoning vulnerability in the affected Next.js versions.
For a request to be exploitable, the affected route also had to be making use of the rewrites feature in Next.js.
The vulnerability is resolved in Next.js 13.5.1 and newer. This includes Next.js 14.x.
There are no official workarounds for this vulnerability. We recommend that you upgrade to a safe version.
https://portswigger.net/web-security/request-smuggling/advanced/response-queue-poisoning
Next.js Allows a Denial of Service (DoS) with Server Actions
A Denial of Service (DoS) attack allows attackers to construct requests that leaves requests to Server Actions hanging until the hosting provider cancels the function execution.
Note: Next.js server is idle during that time and only keeps the connection open. CPU and memory footprint are low during that time.
Deployments without any protection against long running Server Action invocations are especially vulnerable. Hosting providers like Vercel or Netlify set a default maximum duration on function execution to reduce the risk of excessive billing.
This is the same issue as if the incoming HTTP request has an invalid Content-Length header or never closes. If the host has no other mitigations to those then this vulnerability is novel.
This vulnerability affects only Next.js deployments using Server Actions.
This vulnerability was resolved in Next.js 14.2.21, 15.1.2, and 13.5.8. We recommend that users upgrade to a safe version.
There are no official workarounds for this vulnerability.
Thanks to the PackDraw team for responsibly disclosing this vulnerability.
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 Server-Side Request Forgery in Server Actions
A Server-Side Request Forgery (SSRF) vulnerability was identified in Next.js Server Actions by security researchers at Assetnote. If the Host header is modified, and the below conditions are also met, an attacker may be able to make requests that appear to be originating from the Next.js application server itself.
<14.1.1) is running in a self-hosted* manner./.* Many hosting providers (including Vercel) route requests based on the Host header, so we do not believe that this vulnerability affects any Next.js applications where routing is done in this manner.
This vulnerability was patched in #62561 and fixed in Next.js 14.1.1.
There are no official workarounds for this vulnerability. We recommend upgrading to Next.js 14.1.1.
Vercel and the Next.js team thank Assetnote for responsibly disclosing this issue to us, and for working with us to verify the fix. Thanks to:
Adam Kues - Assetnote Shubham Shah - Assetnote
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.
Information exposure in Next.js dev server due to lack of origin verification
A low-severity vulnerability in Next.js has been fixed in version 15.2.2. This issue may have allowed limited source code exposure when the dev server was running with the App Router enabled. The vulnerability only affects local development environments and requires the user to visit a malicious webpage while npm run dev is active.
Because the mitigation is potentially a breaking change for some development setups, to opt-in to the fix, you must configure allowedDevOrigins in your next config after upgrading to a patched version. Learn more.
Learn more: https://vercel.com/changelog/cve-2025-48068
Thanks to sapphi-red and Radman Siddiki for responsibly disclosing this issue.
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
Zod denial of service vulnerability
Zod version 3.22.2 allows an attacker to perform a denial of service while validating emails.
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.