CVE-2026-100409

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.

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.

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:

export default defineCloudflareConfig({
  incrementalCache: staticAssetsIncrementalCache,
  enableCacheInterception: true,
});

An attacker can request:

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/1.1 200 OK
x-opennext-cache: HIT

Protected content

Malformed paths exposed an additional inconsistency. For example:

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/[email protected] 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.

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.

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.

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:

export default defineCloudflareConfig({
  incrementalCache: staticAssetsIncrementalCache,
  enableCacheInterception: true,
});

An attacker can request:

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/1.1 200 OK
x-opennext-cache: HIT

Protected content

Malformed paths exposed an additional inconsistency. For example:

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/[email protected] 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.