GHSA-wjqm-3pj8-j9vc: 
JavaScript vulnerability analysis and mitigation

Summary

OpenNext stores "use cache" entries under a storage key derived from the raw cache key provided by Next.js. That key embeds the serialized arguments of the cached function. The S3 incremental caches (s3, the default, s3-lite, and the S3 part of multi-tier-ddb-s3) and fs-dev build the object key with path.join, which normalizes path segments. As a result, different argument values can map to the same stored entry. An attacker who can pass a string to a "use cache" function can then have their result served to users calling it with another value. With enough ../ segments, the S3 object key also escapes the build ID and the configured CACHE_BUCKET_KEY_PREFIX. s3-lite and multi-tier-ddb-s3 also send the key as a URL path, so the .composable suffix can be escaped too. @opennextjs/cloudflare bundles the same "use cache" handler and is affected through its regional cache and, to a lesser extent, its KV/R2 incremental caches.

Details

For a cached function getPost(slug), the Next.js cache key looks like ["<buildId>","<functionId>",["<slug>"]]. The S3 key is built as:

path.posix.join(CACHE_BUCKET_KEY_PREFIX, BUILD_ID, `${key}.composable`)

path.posix.join collapses //, removes ./ and resolves ../:

Impact

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

1. It uses "use cache" and is deployed with either:
   • @opennextjs/aws with the S3 (s3, the default, or s3-lite) or multi-tier-ddb-s3 incremental cache, or
   • @opennextjs/cloudflare with the regional cache (key normalization) or the KV/R2 incremental cache (lone surrogates in binary arguments only).
2. A "use cache" function receives a request-controlled string argument that is not validated or encoded, or, for KV/R2, a request-controlled binary argument.
3. The function's result for an attacker-chosen value differs meaningfully from its result for the normalized value. Examples: a not-found result, content echoing the argument, or data selected by a path-like identifier. Under these conditions, an unauthenticated attacker can poison the cached result served to other users for a different argument value, for example making a valid entry render as not found until it expires or is revalidated. With the S3 incremental caches, the attacker can also write entries outside the configured key prefix and build ID, which persist across deployments. With s3, the written key always ends with the serialized end of the arguments plus .composable, so overwriting an arbitrary existing entry has not been demonstrated. With s3-lite and multi-tier-ddb-s3, the suffix can be escaped (see Details), so an attacker can overwrite existing entries of other types, such as ISR pages. Those entries hold a composable value, so they are read as a miss and regenerated: the impact is integrity and availability, not content injection.

Severity

Medium (CVSS 3.1: 4.8) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L Attack complexity is rated High because exploitation depends on how the application uses request input as "use cache" arguments.

Patches

The patched version stores "use cache" entries, in both the incremental cache and the tag cache, under the SHA-256 of the exact UTF-16 code units of the Next.js cache key. Every backend receives a fixed-format hex key. Existing "use cache" entries are recomputed once after the upgrade. @opennextjs/cloudflare is fixed by a release that bumps its @opennextjs/aws dependency to the patched version.

Workarounds

Validate request-controlled "use cache" arguments, or encode them before the call so that they cannot contain / (for example lookup(encodeURIComponent(p))), and decode inside the function if needed. This does not cover the lone surrogate collisions on KV/R2 from binary arguments. On @opennextjs/cloudflare, not wrapping the incremental cache with withRegionalCache removes the path normalization (KV/R2 alone are only affected by lone surrogates).