Next.js version 14.2.17 represents a minor update over version 14.2.16, primarily focused on internal package updates and refinements rather than groundbreaking new features. Examining the metadata, both versions share identical dependencies, devDependencies (with the exception of @next/swc and @next/env), peerDependencies, and optionalDependencies, indicating a highly similar core structure. The core dependencies like busboy, postcss, styled-jsx, graceful-fs, @swc/helpers, and caniuse-lite are maintained, ensuring compatibility and stability for existing projects.
The key difference lies in the @next/swc and @next/env devDependency versions, incrementing from 14.2.16 to 14.2.17, suggesting that the primary changes involve updates to the Rust-based compiler and environment variable handling within Next.js. Developers can expect these changes to improve build times and potentially lead to more efficient runtime performance due to the optimized SWC compiler integration. The update might also include enhancements to environment variable loading and processing, offering a more robust and reliable configuration management experience.
While the comprehensive list of devDependencies highlights the extensive toolchain supporting Next.js development, the similarity between the two versions suggests a focus on incremental improvements rather than major API changes. For developers, this implies a smooth upgrade path with minimal disruption, allowing them to leverage the updated SWC compiler and environment handling without significant code modifications. The subtle increase of unpacked size (from ~86.273MB to ~86.272MB, a negliglible decrease) might indicate minor optimization or different packaging of very similar code, too.
All the vulnerabilities related to the version 14.2.17 of the package
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.
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.
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.3
14.2.25
13.5.9
12.3.5
Note: 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.
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