Timneutkens

**Name of the Vulnerable Software and Affected Versions** Next.js versions 14.2.0 through 15.5.15 Next.js versions 16.0.0 through 16.2.4 **Description** Applications using React Server Components (RSC) are susceptible to cache poisoning when shared caches fail to correctly partition response variants. An attacker can manipulate the system to serve an RSC response from the original URL, poisoning shared cache entries. Consequently, subsequent visitors receive component payloads instead of the expected HTML. This occurs due to inconsistent validation and interpretation of `RSC` request headers during request classification and rendering. **Recommendations** Update to version 15.5.16. Update to version 16.2.5. Ensure the CDN or reverse proxy keys on relevant `RSC` request headers and honors `Vary`. Disable shared caching for affected App Router and RSC responses.

**Name of the Vulnerable Software and Affected Versions** App Router applications (affected versions not specified) **Description** Stored cross-site scripting is possible in applications relying on Content Security Policy (CSP) nonces when deployed behind shared caches. Malformed nonce values derived from request headers can be reflected into rendered HTML unsafely, enabling an attacker to poison cached responses and execute scripts for subsequent visitors. CSP nonces are security tokens used to allow only specific inline scripts to execute, preventing unauthorized script injection. **Recommendations** Update the software to a version where malformed nonce values are rejected or ignored and stricter sanitization is applied. Strip inbound `Content-Security-Policy` request headers from untrusted traffic as a temporary workaround.

**Name of the Vulnerable Software and Affected Versions** Next.js versions 13.4.13 through 15.5.15 Next.js versions 16.0.0 through 16.2.4 **Description** Self-hosted applications using the built-in Node.js server are subject to server-side request forgery (SSRF), a condition where an attacker forces a server to make requests to an unintended location. Unauthenticated remote attackers can use crafted absolute-form HTTP requests containing `Upgrade: websocket` headers to force the server to proxy requests to arbitrary internal or external destinations. This can expose internal services, admin panels, private APIs, and cloud metadata endpoints (such as 169.254.169.254), potentially leading to the theft of cloud credentials, API keys, and secrets. Approximately 79,000 instances are estimated to be exposed on Shodan. Vercel-hosted deployments are not affected. **Recommendations** For versions 13.4.13 through 15.5.15, upgrade to version 15.5.16. For versions 16.0.0 through 16.2.4, upgrade to version 16.2.5. As a temporary workaround, block WebSocket upgrades at the reverse proxy or load balancer if they are not required. Restrict origin egress to internal networks and metadata services where possible. Avoid exposing the origin server directly to untrusted networks.

**Name of the Vulnerable Software and Affected Versions** Next.js versions 12.2.0 through 15.5.15 Next.js versions 16.0.0 through 16.2.4 **Description** Applications using the Pages Router with `i18n` configured and middleware or proxy-based authorization may allow unauthorized access to protected page data. This occurs through locale-less requests to the endpoint "/ next/data/<buildId>/<page>.json". In these configurations, middleware does not execute for the unprefixed data route, enabling an attacker to retrieve Server-Side Rendering (SSR) JSON for protected pages by bypassing intended authorization checks. **Recommendations** Update to version 15.5.16. Update to version 16.2.5. Enforce authorization in the page's server-side data path instead of relying solely on middleware.

**Name of the Vulnerable Software and Affected Versions** Next.js versions 15.2.0 through 15.5.15 Next.js versions 16.0.0 through 16.2.4 **Description** App Router applications using middleware or proxy-based authorization checks may allow unauthorized access via transport-specific route variants used for segment prefetching. Specially crafted `.rsc` and segment-prefetch URLs can resolve to the same page without triggering the intended middleware rule, enabling access to protected content without authorization checks. **Recommendations** Update to version 15.5.16. Update to version 16.2.5. Enforce authorization in the underlying route or page logic instead of relying solely on middleware.

**Name of the Vulnerable Software and Affected Versions** Next.js versions 13.0.0 through 15.5.15 Next.js versions 16.0.0 through 16.2.4 **Description** Applications using `beforeInteractive` scripts combined with untrusted content are susceptible to cross-site scripting (XSS), a flaw where malicious scripts are injected into trusted websites. Serialized script content was not safely escaped before being embedded into the document, allowing attacker-controlled input to exit the intended script context and execute arbitrary JavaScript in the visitor's browser. **Recommendations** Update to version 15.5.16. Update to version 16.2.5. Avoid passing untrusted data into `beforeInteractive` scripts. Sanitize or escape content before embedding it if using untrusted data in `beforeInteractive` scripts is unavoidable.

Name of the Vulnerable Software and Affected Versions: Next.js versions prior to 12.0.5 Next.js versions prior to 11.1.3 Description: The issue arises when invalid or malformed URLs are processed, potentially leading to a server crash. This can occur in deployments using Next.js versions above 11.1.0 and below 12.0.5, Node.js above 15.0.0, and next start or a custom server. However, deployments on Vercel and similar environments where invalid requests are filtered before reaching Next.js are not affected. Recommendations: For Next.js versions prior to 12.0.5, update to version 12.0.5 or later to resolve the issue. For Next.js versions prior to 11.1.3, update to version 11.1.3 or later to resolve the issue. As a temporary workaround, consider restricting access to the server or implementing filtering for invalid requests to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Next.js versions prior to 11.1.0 **Description** The issue in Next.js allows an open redirect to occur to an external site when specially encoded paths are used with statically generated pages/ error.js. This redirect does not directly harm users but can allow for phishing attacks by redirecting to an attacker's domain from a trusted domain. **Recommendations** For versions prior to 11.1.0, upgrade to the latest version of Next.js to improve the overall security of your application. As a temporary workaround, consider restricting access to the `pages/ error.js` file until the issue is resolved. Avoid using specially encoded paths in the `pages/ error.js` file to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Next.js versions 9.5.0 through 9.5.3 **Description** The issue allows for an Open Redirect, where specially encoded paths could be used with the trailing slash redirect to allow an open redirect to occur to an external site. This redirect does not directly harm users, although it can allow for phishing attacks by redirecting to an attacker's domain from a trusted domain. **Recommendations** For Next.js versions 9.5.0 through 9.5.3, upgrade to version 9.5.4 to resolve the issue. As a temporary workaround, consider restricting access to specially encoded paths to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Next.js versions prior to 9.3.2 **Description** The issue allows attackers to craft special requests to access files in the dist directory (.next) due to a directory traversal vulnerability. This vulnerability does not affect files outside of the dist directory (.next). In general, the dist directory only holds build assets unless the application intentionally stores other assets under this directory. **Recommendations** For Next.js versions prior to 9.3.2, upgrade to version 9.3.2 to resolve the issue. As a temporary workaround, consider restricting access to the dist directory (.next) to minimize the risk of exploitation.