You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
Patches
The vulnerability is resolved in Next.js 13.5.1 and newer. This includes Next.js 14.x.
Workarounds
There are no official workarounds for this vulnerability. We recommend that you upgrade to a safe version.
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.
Prerequisites
Next.js (<14.1.1) is running in a self-hosted* manner.
The Next.js application makes use of Server Actions.
The Server Action performs a redirect to a relative path which starts with a /.
* 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.
Patches
This vulnerability was patched in #62561 and fixed in Next.js 14.1.1.
Workarounds
There are no official workarounds for this vulnerability. We recommend upgrading to Next.js 14.1.1.
Credit
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:
By sending a crafted HTTP request, it is possible to poison the cache of a non-dynamic server-side rendered route in the pages router (this does not affect the app router). When this crafted request is sent it could coerce Next.js to cache a route that is meant to not be cached and send a Cache-Control: s-maxage=1, stale-while-revalidate header which some upstream CDNs may cache as well.
To be potentially affected all of the following must apply:
Next.js between 13.5.1 and 14.2.9
Using pages router
Using non-dynamic server-side rendered routes e.g. pages/dashboard.tsx not pages/blog/[slug].tsx
This vulnerability was resolved in Next.js v13.5.7, v14.2.10, and later. We recommend upgrading regardless of whether you can reproduce the issue or not.
Workarounds
There are no official or recommended workarounds for this issue, we recommend that users patch to a safe version.
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:
The next.config.js file is configured with images.unoptimized set to true or images.loader set to a non-default value.
The Next.js application is hosted on Vercel.
Patches
This issue was fully patched in Next.js 14.2.7. We recommend that users upgrade to at least this version.
Workarounds
Ensure that the next.config.js file has either images.unoptimized, images.loader or images.loaderFile assigned.
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.
Patches
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.
Workarounds
There are no official workarounds for this vulnerability.
Credits
Thanks to the PackDraw team for responsibly disclosing this vulnerability.
It is possible to bypass authorization checks within a Next.js application, if the authorization check occurs in middleware.
Patches
For Next.js 15.x, this issue is fixed in 15.2.3
For Next.js 14.x, this issue is fixed in 14.2.25
For Next.js 13.x, this issue is fixed in 13.5.9
For Next.js 12.x, this issue is fixed in 12.3.5
For Next.js 11.x, consult the below workaround.
Note: Next.js deployments hosted on Vercel are automatically protected against this vulnerability.
Workaround
If patching to a safe version is infeasible, we recommend that you prevent external user requests which contain the x-middleware-subrequest header from reaching your Next.js application.
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.
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.
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.
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.
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.
[!NOTE]
This release is backporting bug fixes. It does not include all pending features/changes on canary.
This release contains a security patch for CVE-2025-29927.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
13.5.6
->14.2.32
GitHub Vulnerability Alerts
CVE-2023-46298
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.
CVE-2024-34350
Impact
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.
Patches
The vulnerability is resolved in Next.js
13.5.1
and newer. This includes Next.js14.x
.Workarounds
There are no official workarounds for this vulnerability. We recommend that you upgrade to a safe version.
References
https://portswigger.net/web-security/request-smuggling/advanced/response-queue-poisoning
CVE-2024-34351
Impact
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.Prerequisites
<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.
Patches
This vulnerability was patched in #62561 and fixed in Next.js
14.1.1
.Workarounds
There are no official workarounds for this vulnerability. We recommend upgrading to Next.js
14.1.1
.Credit
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
CVE-2024-46982
Impact
By sending a crafted HTTP request, it is possible to poison the cache of a non-dynamic server-side rendered route in the pages router (this does not affect the app router). When this crafted request is sent it could coerce Next.js to cache a route that is meant to not be cached and send a
Cache-Control: s-maxage=1, stale-while-revalidate
header which some upstream CDNs may cache as well.To be potentially affected all of the following must apply:
pages/dashboard.tsx
notpages/blog/[slug].tsx
The below configurations are unaffected:
Patches
This vulnerability was resolved in Next.js v13.5.7, v14.2.10, and later. We recommend upgrading regardless of whether you can reproduce the issue or not.
Workarounds
There are no official or recommended workarounds for this issue, we recommend that users patch to a safe version.
Credits
CVE-2024-47831
Impact
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 withimages.unoptimized
set totrue
orimages.loader
set to a non-default value.Patches
This issue was fully patched in Next.js
14.2.7
. We recommend that users upgrade to at least this version.Workarounds
Ensure that the
next.config.js
file has eitherimages.unoptimized
,images.loader
orimages.loaderFile
assigned.Credits
Brandon Dahler (brandondahler), AWS
Dimitrios Vlastaras
CVE-2024-39693
Impact
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.
Patches
This vulnerability was resolved in Next.js 13.5 and later. We recommend that users upgrade to a safe version.
Workarounds
There are no official workarounds for this vulnerability.
Credit
CVE-2024-51479
Impact
If a Next.js application is performing authorization in middleware based on pathname, it was possible for this authorization to be bypassed.
Patches
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.
Workarounds
There are no official workarounds for this vulnerability.
Credits
We'd like to thank tyage (GMO CyberSecurity by IERAE) for responsible disclosure of this issue.
CVE-2024-56332
Impact
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.
Patches
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.
Workarounds
There are no official workarounds for this vulnerability.
Credits
Thanks to the PackDraw team for responsibly disclosing this vulnerability.
CVE-2025-29927
Impact
It is possible to bypass authorization checks within a Next.js application, if the authorization check occurs in middleware.
Patches
15.2.3
14.2.25
Note: Next.js deployments hosted on Vercel are automatically protected against this vulnerability.
Workaround
If patching to a safe version is infeasible, we recommend that you prevent external user requests which contain the
x-middleware-subrequest
header from reaching your Next.js application.Credits
CVE-2025-48068
Summary
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
Credit
Thanks to sapphi-red and Radman Siddiki for responsibly disclosing this issue.
CVE-2025-57752
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
orAuthorization
), 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
CVE-2025-57822
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
CVE-2025-55173
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
orimages.remotePatterns
are encouraged to upgrade and verify that external image sources are strictly validated.More details at Vercel Changelog
CVE-2025-32421
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.Learn more here
Credit
Thank you to Allam Rachid (zhero) for the responsible disclosure. This research was rewarded as part of our bug bounty program.
Release Notes
vercel/next.js (next)
v14.2.32
Compare Source
v14.2.31
Compare Source
Core Changes
Credits
Huge thanks to @styfle and @ztanner for helping!
v14.2.30
Compare Source
v14.2.29
Compare Source
v14.2.28
Compare Source
Core Changes
Credits
Huge thanks to @ztanner for helping!
v14.2.27
Compare Source
Core Changes
Credits
Huge thanks to @ztanner for helping!
v14.2.26
Compare Source
Core Changes
v14.2.25
Compare Source
Core Changes
Credits
Huge thanks to @ijjk for helping!
v14.2.24
Compare Source
Core Changes
Credits
Huge thanks to @ztanner for helping!
v14.2.23
Compare Source
Core Changes
Credits
Huge thanks to @styfle, @ijjk and @lubieowoce for helping!
v14.2.22
Compare Source
Core Changes
Credits
Huge thanks to @unstubbable, @ijjk, and @ztanner for helping!
v14.2.21
Compare Source
Core Changes
14898b6
to178c267
: #74115Misc Changes
Credits
Huge thanks to @unstubbable, @ztanner, and @styfle for helping!
v14.2.20
Compare Source
Core Changes
Credits
Huge thanks to @wyattjoh for helping!
v14.2.19
Compare Source
Core Changes
Misc Changes
Credits
Huge thanks to @ztanner and @ijjk for helping!
v14.2.18
Compare Source
Core Changes
Credits
Huge thanks to @huozhi and @ijjk for helping!
v14.2.17
Compare Source
Core Changes
Credits
Huge thanks to @huozhi, @ztanner, and @ijjk for helping!
v14.2.16
Compare Source
v14.2.15
Compare Source
Core Changes
Credits
Huge thanks to @ztanner, @agadzik, @huozhi, @styfle, @icyJoseph and @wyattjoh for helping!
v14.2.14
Compare Source
Core Changes
Credits
Huge thanks to @styfle, @ztanner, @ijjk, @huozhi and @wyattjoh for helping!
v14.2.13
Compare Source
Core Changes
Credits
Huge thanks to @raeyoung-kim, @huozhi, @devjiwonchoi, and @ijjk for helping!
v14.2.12
Compare Source
Core Changes
Credits
Huge thanks to @alvarlagerlof, @wyattjoh, @delbaoliveira, and @ijjk for helping!
v14.2.11
Compare Source
Core Changes
Credits
Huge thanks to @huozhi, @devjiwonchoi, and @ijjk for helping!
v14.2.10
Compare Source
Core Changes
Credits
Huge thanks to @huozhi and @ijjk for helping!
v14.2.9
Compare Source
Core Changes
Credits
Huge thanks to @huozhi, @ztanner, @ijjk, and @lubieowoce for helping!
v14.2.8
Compare Source
What's Changed
Support
esmExternals
in app directoryReading cookies set in middleware in components and actions
Metadata and icons
fb:app_id
,fb:admins
) in generateMetaData (#65713)Parallel routes fixes
Draft mode and edge improvements
next/image
fixesServer actions improvements
Other changes
Create-next-app updates
create-next-app
template CSS (#66043)create-next-app
public/ assets from local folder→ remote URL (#66931)Full Changelog: vercel/next.js@v14.2.7...v14.2.8
Huge thanks to everyone who contributed to this release:
@abhi12299, @delbaoliveira, @eps1lon, @ForsakenHarmony, @huozhi, @ijjk, @JoshuaKGoldberg, @leerob, @lubieowoce, @Netail, @ronanru, @samcx, @shuding, @sokra, @stylessh, @timfuhrmann, @wbinnssmith, @wyattjoh, @ypessoa, @ztanner
v14.2.7
Compare Source
Core Changes
Credits
Huge thanks to @kjugi, @huozhi, @ztanner, @SukkaW, @marlier, @Kikobeats, @syi0808, @ijjk, and @samcx for helping!
v14.2.6
Compare Source
Core Changes
v14.2.5
Compare Source
Core Changes
Misc
Credits
Huge thanks to @devjiwonchoi, @ijjk, @emmerich, @huozhi, @kdy1, @kwonoj, @styfle, and @sokra for helping!
v14.2.4
Compare Source
Core Changes
Credits
Huge thanks to @ztanner, @ijjk, @wbinnssmith, @huozhi, and @lubieowoce for helping!
v14.2.3
Compare Source
Core Changes
Credits
Huge thanks to @huozhi, @samcx, @ztanner, @Jeffrey-Zutt, and @ijjk for helping!
v14.2.2
Compare Source
Core Changes
Credits
Huge thanks to @shuding, @coltonehrman, @ztanner, @huozhi, @sokra, @Jeffrey-Zutt, @timneutkens, @wbinnssmith, @wiesson, @ijjk, @devjiwonchoi, and @bgw for helping!
v14.2.1
Compare Source
Core Changes
Credits
Huge thanks to @sokra for helping!
v14.2.0
Compare Source
Learn more: https://nextjs.org/blog/next-14-2
Core Changes
next info
output: #60376terser
tov5.27.0
: #61068swc_core
tov0.87.28
: #60876unoptimized
prop: #61045Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.