GHSA-xm22-g823-hr53: 
JavaScript vulnerability analysis and mitigation

Summary

When application code sets cookies with NextResponse#cookies, the cookies written to that NextResponse, HttpOnly ones included, are also copied into the internal x-middleware-set-cookie header. The header only exists so that cookies() can see cookies set by the middleware during the same request. It must be forwarded on the request only and never sent to the client. OpenNext could send this header to the client in several response paths. The HttpOnly cookie values then appear in a regular response header. Unlike the Set-Cookie header, it can be read with fetch() / XMLHttpRequest by scripts running in the page. This defeats the HttpOnly protection.

Details

NextResponse sets the header in next/dist/server/web/spec-extension/response.js whenever response.cookies.set() / delete() is called. OpenNext is expected to keep it internal:

• for middleware, forward it on the request only, so that cookies().get() sees the new values;
• never include it in a response sent to the client, including responses served from the cache. OpenNext did not do this in the following paths:

1. Middleware direct responses (NextResponse.json(), NextResponse.redirect(), new NextResponse(...)). core/routing/middleware.ts copied the header into the response returned to the client. This path does not require cache interception or a custom asset resolver.
2. Middleware next() / rewrite(). The header was kept in the middleware response headers, and routingHandler applies those to the final result. The guard in core/requestHandler.ts covers rendered responses, so these are not affected. The header was exposed when the result was served directly by OpenNext's routing layer instead of being rendered:
   • by the cache interceptor, when dangerous.enableCacheInterception is enabled and the requested SSG/ISR page is a cache hit;
   • by an asset resolver override that implements maybeGetAssetResult. The default AWS resolver does not.
3. Cache hits for route handlers. With dangerous.enableCacheInterception enabled, core/routing/cacheInterceptor.ts returned every header stored in the cache entry. A cached route handler that sets response.cookies stores the header in the cache, and it was sent on every hit. Without cache interception, these hits are not affected.
4. Edge route handlers. adapters/edge-adapter.ts copied every response header.

Impact

Affected OpenNext versions can expose HttpOnly cookie values written through NextResponse#cookies when the response passes through one of the affected, unsanitized paths. Typical examples are session or authentication cookies.

• Their values are exposed in a response header readable by client-side JavaScript. An XSS or a malicious third-party script can steal cookies that HttpOnly was meant to protect.
  • Direct middleware responses expose them with the default configuration.
  • Middleware cookies set on NextResponse.next() / rewrite() are exposed with cache interception enabled, when the requested SSG/ISR page is a cache hit, or with a custom asset resolver implementing maybeGetAssetResult.
  • Cookies set by cached route handlers are exposed on every cache hit with cache interception enabled. The same value is sent to every visitor.
  • Cookies set by edge route handlers are exposed regardless of cache interception.
  • Redirect responses are not readable by page scripts.
• The values can also be recorded by intermediaries or tools that log response headers. This includes redirect responses.

Workarounds

Until you upgrade:

• Avoid setting HttpOnly cookies through NextResponse#cookies in middleware, cached route handlers or edge route handlers. Set them with response.headers.append("Set-Cookie", ...) instead, which does not populate x-middleware-set-cookie. Do not call response.cookies.set() / delete() on the same response, as it rewrites the Set-Cookie headers and drops the appended cookies. Cookies set this way on NextResponse.next() are not visible to cookies() during the same request.
• Disabling dangerous.enableCacheInterception mitigates the cache-interceptor vectors. It does not mitigate direct middleware responses, the asset-resolver vector, or affected edge-handler responses.
• Alternatively, strip the x-middleware-set-cookie response header at the CDN or proxy in front of OpenNext, for example with a CloudFront response headers policy or a Cloudflare Transform Rule. Apply it to all client-facing responses, including cached and redirect responses, and only remove x-middleware-set-cookie, keeping the Set-Cookie headers. Make sure OpenNext cannot be reached through an endpoint that bypasses that rule, for example a Lambda Function URL or the default API Gateway endpoint.