CVE-2026-100409

## Summary When cache interception is enabled, `@opennextjs/cloudflare` can interpret percent-encoded paths differently during middleware matching and cache lookup. An encoded request may fail to match authorization middleware, then be decoded into the cache key of a protected route. The cached response may consequently be returned without invoking the middleware. `enableCacheInterception` is disabled by default. ## Impact A remote unauthenticated attacker may retrieve cached content from routes intended to be protected by middleware. An application is affected when it: - explicitly enables `enableCacheInterception`; - relies on middleware for access control; and - has a matching cached route. ## Details Middleware matching previously used the encoded request pathname, while cache interception decoded the pathname before selecting a cache entry. For example, consider an application with: - middleware matcher `/admin/:path*`; - middleware returning `401 Authentication required` for `/admin`; - a statically generated, cached `/admin` route; and - cache interception enabled: ```ts export default defineCloudflareConfig({ incrementalCache: staticAssetsIncrementalCache, enableCacheInterception: true, }); ``` An attacker can request: ```http GET /%61dmin ``` The encoded pathname does not match `/admin/:path*`, so the authorization middleware is not invoked. Cache interception then decodes `%61dmin` to `admin` and may return the cached `/admin` response: ```http HTTP/1.1 200 OK x-opennext-cache: HIT Protected content ``` Malformed paths exposed an additional inconsistency. For example: ```http GET /%61dmin/%ZZ ``` The previous implementation decoded each segment independently. It decoded `%61dmin` to `admin` but retained the malformed `%ZZ` segment, allowing cache lookup to continue using a partially decoded pathname. ## Patches The fix aligns encoded-path handling across middleware matching and cache lookup, and rejects malformed paths instead of