GHSA-r93v-v56c-m225: 
JavaScript vulnerability analysis and mitigation

Summary

When OpenNext runs with the node wrapper (or express-dev), a stale Content-Length header can be written to the client connection together with a longer body. If the app sits behind a reverse proxy that reuses or pipelines backend connections, the bytes past the declared length can be parsed as the response to another client's request. An attacker who controls an upstream that the app fetches can use this to inject a response for another user, or to receive a response meant for another user. This is the OpenNext counterpart of the upstream Next.js advisory GHSA-pc58-hwjq-p385.

Details

Node.js fetch (undici) decodes a compressed upstream body but keeps the upstream Content-Length (the compressed size) and Content-Encoding headers on the Response. When a Route Handler returns that Response unchanged, Next.js copies every header to the response. The Next.js fetch cache and route cache also store the decoded body together with the original headers, so the mismatch survives cache hits. The node and express-dev wrappers pass these headers straight to ServerResponse.writeHead() and then stream the longer, decoded body. Node.js does not enforce Content-Length by default (strictContentLength is false), so it writes every byte to the keep-alive socket. Other OpenNext code paths feed stale headers into the same place:

• A middleware returning a fetch() response: content-encoding was already dropped, but content-length was kept.
• The fetch external-rewrite proxy (proxyExternalRequest: "fetch", opt-in on AWS).
• Cache interception (dangerous.enableCacheInterception) replaying route entries. Not affected:
• The Lambda wrappers (aws-lambda, aws-lambda-compressed, aws-lambda-streaming, aws-apigw-streaming, Lambda@Edge): AWS builds the HTTP response sent to the client. A stale header can make the response undecodable for the client, but one client's bytes cannot leak into another client's response.
• The Cloudflare wrappers: workerd ignores a user-set Content-Length and frames the response itself.

Impact

An application is affected when all of the following are true:

1. It is deployed with @opennextjs/aws using the node wrapper (for example in a container behind a load balancer). express-dev is affected too, but it is meant for local development. The legacy open-next package (3.0.0 to 3.1.3) has the same node wrapper and is affected too. It will not be patched. Migrate to @opennextjs/aws.
2. A stale Content-Length from a compressed upstream reaches the wrapper: a route handler or middleware returns a fetch() response unchanged, an external rewrite is proxied with proxyExternalRequest: "fetch", or cache interception replays a route entry stored with such headers. The upstream must be attacker-controlled or able to return attacker-influenced compressed content.
3. A reverse proxy in front of the app keeps multiple clients' requests outstanding on one backend HTTP/1.1 connection, and does not reject extra bytes after a complete response. Under these conditions, an unauthenticated attacker can desynchronize responses between clients: a victim receives an attacker-crafted response, and the attacker can receive the victim's response, including authenticated content.

Severity

Medium (CVSS 3.1: 6.5) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N Attack complexity is rated High because exploitation requires an application route forwarding attacker-influenced compressed upstream content, and a specific reverse proxy behaviour.

Patches

In the patched version, the node and express-dev wrappers no longer forward transfer-encoding to the Node.js ServerResponse, and only keep a valid content-length when the body has exactly the declared length (or for HEAD and 304 responses, which have no body). Otherwise Node.js frames the body itself. To verify the length, responses with a content-length up to 10 MB are sent once the whole body is received. Responses without a content-length are still streamed. This covers all the code paths listed above, as they all reach the client through the wrapper. Upgrading Next.js to the version that fixes GHSA-pc58-hwjq-p385 only fixes route handlers. Middleware, the fetch proxy and cache interception need the OpenNext patch.

Workarounds

• In route handlers and middleware, do not return a fetched Response unchanged. Copy it without the framing and encoding headers:

  const upstream = await fetch(url);
  const headers = new Headers(upstream.headers);
  for (const name of ['content-length', 'transfer-encoding', 'content-encoding']) headers.delete(name);
  return new Response(upstream.body, { status: upstream.status, headers });

• With proxyExternalRequest: "fetch", switch back to the default node proxy, which drops the upstream content-length and content-encoding.
• Or make sure the reverse proxy in front of the node wrapper doesn't pipeline requests from different clients on a backend connection and closes connections with unexpected extra data.

References

• Upstream Next.js advisory: GHSA-pc58-hwjq-p385