GHSA-2VC4-C4R6-P6V6
Vulnerability from github – Published: 2026-10-15 20:15 – Updated: 2026-10-15 20:15Summary
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 requiredfor/admin; - a statically generated, cached
/adminroute; 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/cloudflare@1.20.2 or later.
Workarounds
If upgrading is not immediately possible for an application:
- Disable cache interception by removing
enableCacheInterception: true. - Enforce authorization inside protected route handlers rather than relying exclusively on middleware.
- 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.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@opennextjs/cloudflare"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.0"
},
{
"fixed": "1.20.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-100409"
],
"database_specific": {
"cwe_ids": [
"CWE-177",
"CWE-180"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-15T20:15:17Z",
"nvd_published_at": "2026-10-15T17:17:07Z",
"severity": "HIGH"
},
"details": "## Summary\n\nWhen cache interception is enabled, `@opennextjs/cloudflare` can interpret percent-encoded paths differently during middleware matching and cache lookup.\n\nAn 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.\n\n`enableCacheInterception` is disabled by default.\n\n## Impact\n\nA remote unauthenticated attacker may retrieve cached content from routes intended to be protected by middleware.\n\nAn application is affected when it:\n\n- explicitly enables `enableCacheInterception`;\n- relies on middleware for access control; and\n- has a matching cached route.\n\n## Details\n\nMiddleware matching previously used the encoded request pathname, while cache interception decoded the pathname before selecting a cache entry.\n\nFor example, consider an application with:\n\n- middleware matcher `/admin/:path*`;\n- middleware returning `401 Authentication required` for `/admin`;\n- a statically generated, cached `/admin` route; and\n- cache interception enabled:\n\n```ts\nexport default defineCloudflareConfig({\n incrementalCache: staticAssetsIncrementalCache,\n enableCacheInterception: true,\n});\n```\n\nAn attacker can request:\n\n```http\nGET /%61dmin\n```\n\nThe 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:\n\n```http\nHTTP/1.1 200 OK\nx-opennext-cache: HIT\n\nProtected content\n```\n\nMalformed paths exposed an additional inconsistency. For example:\n\n```http\nGET /%61dmin/%ZZ\n```\n\nThe 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.\n\n## Patches\n\nThe 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](https://github.com/opennextjs/opennextjs-aws/pull/1199) and [opennextjs-aws#1200](https://github.com/opennextjs/opennextjs-aws/pull/1200).\n\nUsers should upgrade to `@opennextjs/cloudflare@1.20.2` or later.\n\n## Workarounds\n\nIf upgrading is not immediately possible for an application:\n\n1. Disable cache interception by removing `enableCacheInterception: true`.\n2. Enforce authorization inside protected route handlers rather than relying exclusively on middleware.\n3. Reject encoded paths for protected routes at a trusted proxy before they reach the Worker.\n\nAdding individual encoded matcher variants is not a complete workaround because pathnames can have multiple equivalent encodings.",
"id": "GHSA-2vc4-c4r6-p6v6",
"modified": "2026-10-15T20:15:17Z",
"published": "2026-10-15T20:15:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opennextjs/opennextjs-cloudflare/security/advisories/GHSA-2vc4-c4r6-p6v6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100409"
},
{
"type": "WEB",
"url": "https://github.com/opennextjs/opennextjs-aws/pull/1199"
},
{
"type": "WEB",
"url": "https://github.com/opennextjs/opennextjs-aws/pull/1200"
},
{
"type": "WEB",
"url": "https://github.com/opennextjs/opennextjs-cloudflare/commit/38ea40b669be272ddf09a7df7e70c69d0b57404b"
},
{
"type": "PACKAGE",
"url": "https://github.com/opennextjs/opennextjs-cloudflare"
},
{
"type": "WEB",
"url": "https://github.com/opennextjs/opennextjs-cloudflare/releases/tag/@opennextjs/cloudflare@1.20.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenNext Cloudflare: Cache interception can bypass middleware protection for encoded paths"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.