CVE-2026-100409: OpenNext Cloudflare: Cache interception can bypass middleware protection for encoded paths
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 partially decoding them. See the upstream fixes in opennextjs-aws#1199 and opennextjs-aws#1200.
Users should upgrade to @opennextjs/cloudflare@1.20.2 or later.
Workarounds
If upgrading is not immediately possible for an application:
1. Disable cache interception by removing enableCacheInterception: true. 2. Enforce authorization inside protected route handlers rather than relying exclusively on middleware. 3. Reject encoded paths for protected routes at a trusted proxy before they reach the Worker.
Adding individual encoded matcher variants is not a complete workaround because pathnames can have multiple equivalent encodings.
Other sources
OpenNext Cloudflare is an open Next.js adapter for Cloudflare. From 0.3.0 until 1.20.2, applications that enable enableCacheInterception, rely on middleware for access control, and have a matching cached protected route process encoded pathnames inconsistently between middleware matching and cache lookup. An unauthenticated attacker can use a percent-encoded pathname that does not match authorization middleware but decodes to the cache key of a protected route, causing cached content to be returned without authorization. Malformed encodings can also be partially decoded, allowing cache lookup to continue with a pathname that middleware did not evaluate consistently. This issue is fixed in version 1.20.2.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@opennextjs/cloudflareto a version that resolves this vulnerability.Fixed in 1.20.2 - Upgrade
Upgrade
@opennextjs/cloudflareto a version that resolves this vulnerability.Fixed in 1.20.2 - Configuration
Disable cache interception by removing enableCacheInterception: true.
@opennextjs/cloudflare enableCacheInterception = false - Compensating control
Enforce authorization inside protected route handlers rather than relying exclusively on middleware.
- Compensating control
Reject encoded paths for protected routes at a trusted proxy before they reach the Worker.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using npm/@opennextjs/cloudflare from version 0.3.0 through versions before 1.20.2 are affected only when enableCacheInterception is enabled, middleware is used for access control, and a protected route has a matching cached response.
What does an attacker need to exploit the bypass?
No authentication or user interaction is required. An attacker must request a specially percent-encoded pathname that avoids the authorization middleware match but decodes to the cache key of a protected route.
What content can be exposed?
Cached content for a protected route can be returned without authorization. The issue affects confidentiality; the provided data does not indicate integrity or availability impact.
How can this be remediated?
Upgrade OpenNext Cloudflare to version 1.20.2, which fixes the issue. If an immediate upgrade is not possible, the affected condition depends on enableCacheInterception being enabled and middleware being relied on for access control.