Package Instance

Next.js: HTTP request smuggling in rewrites
## Summary
When Next.js rewrites proxy traffic to an external backend, a crafted `DELETE`/`OPTIONS` request using `Transfer-Encoding: chunked` could trigger request boundary disagreement between the proxy and backend. This could allow request smuggling through rewritten routes.

## Impact
An attacker could smuggle a second request to unintended backend routes (for example, internal/admin endpoints), bypassing assumptions that only the configured rewrite destination/path is reachable. This does not impact applications hosted on providers that handle rewrites at the CDN level, such as Vercel. 

## Patches
The vulnerability originated in an upstream library vendored by Next.js. It is fixed by updating that dependency’s behavior so `content-length: 0` is added only when both `content-length` and `transfer-encoding` are absent, and `transfer-encoding` is no longer removed in that code path.

## Workarounds
If upgrade is not immediately possible:
- Block chunked `DELETE`/`OPTIONS` requests on rewritten routes at your edge/proxy.
- Enforce authentication/authorization on backend routes per our [security guidance](https://nextjs.org/docs/app/guides/data-security).

Next.js: null origin can bypass Server Actions CSRF checks
## Summary
`origin: null` was treated as a "missing" origin during Server Action CSRF validation. As a result, requests from opaque contexts (such as sandboxed iframes) could bypass origin verification instead of being validated as cross-origin requests.

## Impact
An attacker could induce a victim browser to submit Server Actions from a sandboxed context, potentially executing state-changing actions with victim credentials (CSRF).

## Patches
Fixed by treating `'null'` as an explicit origin value and enforcing host/origin checks unless `'null'` is explicitly allowlisted in `experimental.serverActions.allowedOrigins`.  

## Workarounds
If upgrade is not immediately possible:
- Add CSRF tokens for sensitive Server Actions.
- Prefer `SameSite=Strict` on sensitive auth cookies.
- Do not allow `'null'` in `serverActions.allowedOrigins` unless intentionally required and additionally protected.

Next.js: Unbounded postponed resume buffering can lead to DoS
## Summary
A request containing the `next-resume: 1` header (corresponding with a PPR resume request) would buffer request bodies without consistently enforcing `maxPostponedStateSize` in certain setups. The previous mitigation protected minimal-mode deployments, but equivalent non-minimal deployments remained vulnerable to the same unbounded postponed resume-body buffering behavior.

## Impact
In applications using the App Router with Partial Prerendering capability enabled (via `experimental.ppr` or `cacheComponents`), an attacker could send oversized `next-resume` POST payloads that were buffered without consistent size enforcement in non-minimal deployments, causing excessive memory usage and potential denial of service.

## Patches
Fixed by enforcing size limits across all postponed-body buffering paths and erroring when limits are exceeded.  

## Workarounds
If upgrade is not immediately possible:
- Block requests containing the `next-resume` header, as this is never valid to be sent from an untrusted client.

Next.js: Unbounded next/image disk cache growth can exhaust storage
## Summary
The default Next.js image optimization disk cache (`/_next/image`) did not have a configurable upper bound, allowing unbounded cache growth.

## Impact
An attacker could generate many unique image-optimization variants and exhaust disk space, causing denial of service. Note that this does not impact platforms that have their own image optimization capabilities, such as Vercel.

## Patches
Fixed by adding an LRU-backed disk cache with `images.maximumDiskCacheSize`, including eviction of least-recently-used entries when the limit is exceeded. Setting `maximumDiskCacheSize: 0` disables disk caching. 

## Workarounds
If upgrade is not immediately possible:
- Periodically clean `.next/cache/images`.
- Reduce variant cardinality (e.g., tighten values for `images.localPatterns`, `images.remotePatterns`, and `images.qualities`)

Next.js: null origin can bypass dev HMR websocket CSRF checks
## Summary
In `next dev`, cross-site protections for internal development endpoints could treat `Origin: null` as a bypass case even when [`allowedDevOrigins`](https://nextjs.org/docs/app/api-reference/config/next-config-js/allowedDevOrigins) is configured. This could allow privacy-sensitive or opaque browser contexts, such as sandboxed documents, to access privileged internal dev-server functionality unexpectedly.

## Impact
If a developer visits attacker-controlled content while running an affected `next dev` server with [`allowedDevOrigins`](https://nextjs.org/docs/app/api-reference/config/next-config-js/allowedDevOrigins) configured, attacker-controlled browser code may be able to connect to internal development endpoints and interact with sensitive dev-server functionality that should have remained blocked.

This issue affects development mode only. It does not affect `next start`, and it does not expose internal debugging functionality to the network by default.

## Patches
Fixed by validating `Origin: null` through the same cross-site origin-allowance checks used for other origins on internal development endpoints.

## Workarounds
If upgrade is not immediately possible:
- Do not expose `next dev` to untrusted networks.
- If you use [`allowedDevOrigins`](https://nextjs.org/docs/app/api-reference/config/next-config-js/allowedDevOrigins), reject requests and websocket upgrades with `Origin: null` for internal dev endpoints at your proxy.