CVE-2026-103004

Executive Summary

CVE-2026-103004 is a cache-key confusion vulnerability affecting Next.js versions 16.3.0 through 16.3.7 when Cache Components are enabled via cacheComponents: true. Under specific conditions involving nested use cache functions that read root params through next/root-params, the enclosing cache entry's key omits the root param, causing the entry to be written once and reused across all root param values. This results in the return value of one cached invocation being served to requests for a different root param value, with shared cache headers propagating the cross-context content further downstream. Organizations running affected Next.js versions with Cache Components enabled are impacted; the issue is patched in 16.3.8 and no public PoC or active exploitation is currently known.

Technical Analysis

The vulnerability resides in Next.js's cache key derivation logic within the use cache directive implementation. Next.js 16 introduced Cache Components (cacheComponents: true), an opt-in model where 'use cache' functions are keyed by their arguments and by implicitly-tracked dynamic values. The next/root-params module exposes root segment parameters to components and functions; when a cached function reads such a param, that param is supposed to contribute to the enclosing function's cache key, ensuring distinct cache entries per root param value.

The failure mode is a nesting/consistency defect in key construction:

1. An outer 'use cache' function F_outer calls an inner 'use cache' function F_inner.
2. F_inner reads one or more root params via next/root-params and is therefore keyed on those params.
3. When F_inner's call is served from an existing cache entry (a hit), the implicit dependency on the root param is not propagated back up to F_outer. F_outer's cache key is consequently computed without that root param.
4. F_outer's entry — including whatever response content it produced — is written once, keyed only on the params visible at that point.
5. All subsequent invocations of F_outer, regardless of the actual root param value in the request, resolve to that same entry.

The net effect is cache key confusion (CWE-524: Use of Cache Containing Sensitive Information / observable key mis-scoping): the mapping between a request's root param context and served content is broken. Content rendered for root param value A can be served to requests whose root param value is B.

Per the NVD description, the defect manifests regardless of rendering strategy — prerendered at build time, prerendered at runtime, or rendered dynamically — which means the mis-keyed entry can be materialized in the build output or in the runtime cache. When cache headers are shared (e.g., Cache-Control / surrogate keys configured to allow shared or downstream caching), the incorrectly-scoped response can be redistributed by CDNs, reverse proxies, and other intermediary caches, expanding the population of clients that receive the wrong content.

Two properties of the flaw constrain exploitation and shape its severity:

• Attacker control is absent on the value dimension. The NVD description explicitly states that "what values are leaked cannot be attacker controlled." An attacker cannot choose which root param value's content is exposed.
• Ordering determines exposure. Which value's content is served is determined solely by which invocation writes the cache entry first ("Which value's content is served depends only on which invocation wrote the entry first"). This makes the outcome a race/ordering artifact rather than a deterministic, attacker-selected data disclosure.

Root params are typically used to scope content by a top-level route or tenant segment. That class of parameter is precisely what one would expect to distinguish one customer's content from another's, or one localization/region view from another. A cache key that omits this dimension therefore undermines the isolation boundary the parameter was designed to enforce.

No CVE-level CVSS vector was published with this record (CVSS Score: N/A) and the vulnerability has not been scored by FIRST.org at the time of writing. The vector shown in METADATA is an analyst-constructed estimate based on the described mechanism (network-reachable, high complexity due to ordering/nesting preconditions, no privileges or user interaction required, high confidentiality impact from cross-context content disclosure, no integrity or availability impact) and should be treated as provisional.

Exploitation Scenarios

There is no public proof-of-concept, exploit code, or Nuclei template for CVE-2026-103004. The following chain is inferred strictly from the vulnerability class (cache key confusion) and the mechanism stated in the NVD description; no implementation specifics beyond those named in the description (use cache, next/root-params, cacheComponents: true) are asserted.

1. Reconnaissance / target identification. An attacker fingerprints Next.js deployments running versions in the 16.3.0–16.3.7 range. Standard fingerprints include build manifest references and framework headers/asset paths. The attacker then determines whether Cache Components are active (cacheComponents: true) by observing cache-header behavior on repeated requests, and whether the application's routing exposes root-level parameters (the next/root-params surface) — for example, top-level segment-scoped views such as tenant, locale, or region roots.

2. Triggering the flaw class. The attacker issues requests that cause the nested use cache path to execute: an outer cached function invoking an inner cached function that reads a root param. The critical condition is the inner cache being a hit while the outer function's key is being computed without the root param. The attacker does not need to craft a malicious payload; the objective is to influence ordering — to cause the application to populate the enclosing cache entry first for one root param value (value A), so that the entry is thereafter reused for requests carrying a different root param value (value B).

3. Execution method (vulnerability class level). There is no injection, no code execution, and no request parameter that is directly weaponized. The "payload" is simply a request that lands on the vulnerable code path at the right point in the cache lifecycle — after the inner entry exists, and as the first writer of the outer entry for the relevant key. Because the flaw is ordering-dependent, repeated requests and timing relative to cache warm-up (including build-time prerender artifacts) govern which value ends up cached under the mis-scoped key.

4. Post-exploitation impact. Once the outer entry is written for value A and reused for value B, responses intended for A's context are served to B's requests. Where root params demarcate tenants, accounts, regions, or localized content, this constitutes cross-context content disclosure. If cache headers permit shared caching, downstream CDNs and proxies redistribute the mis-scoped content, widening the audience that receives it. Because neither the value nor the content is attacker-controlled, the attacker's realized gain is opportunistic — but from a defender's perspective the confidentiality boundary has failed, and the disclosed content may include data the receiving context was never authorized to see.

Because exploitation depends on application-specific cache topology (nesting of use cache functions, root param usage, shared cache configuration), not every deployment of an affected version is exploitable. Deployments that do not enable cacheComponents: true, or that do not nest cached functions reading root params, are not impacted by this specific defect.

Impact Assessment

The primary impact is confidentiality loss through cross-context content disclosure. Root params exist to scope content; a cache key that drops that dimension directly undermines that scoping. Where the root param encodes a tenant, organization, account, region, or locale boundary, the practical impact is that one context's rendered response can be served into another context.

Business consequences to consider:

• Cross-tenant or cross-customer data exposure in multi-tenant SaaS built on Next.js with root-param-scoped routing and nested cached data access, potentially with regulatory and contractual notification obligations.
• Privacy/regulatory exposure where the leaked content contains personal data, and where shared/downstream caches extend the set of recipients.
• Erosion of cache correctness guarantees more broadly — the same defect class can serve stale or wrong-context content even in non-sensitive render paths, producing incorrect localized or segmented views.
• No integrity or availability impact is described: the flaw does not permit modification of stored content or denial of service. CVSS integrity and availability subscores are therefore low/unscored in the analyst estimate.

Blast radius is bounded by two conditions: (a) affected Next.js version and Cache Components enabled, and (b) an application structure that nests 'use cache' functions with an inner function reading a root param. Within those conditions, exposure is amplified by shared cache headers that allow intermediary caches to redistribute the mis-scoped response. Because the vulnerability has not been added to CISA KEV, no confirmed in-the-wild exploitation, and no public PoC, the current threat level is driven by latent exposure rather than observed attack activity. The absence of a vendor-published CVSS score means organizations should apply their own environmental scoring, weighting confidentiality and any multi-tenant data classification heavily.

Detection Guidance

Detection for this issue is inherently indirect: there is no exploit payload to match. The signals described below target the symptom (identical cached responses served across differing root-param contexts / anomalous cache-key cardinality) and the build/runtime configuration that enables the vulnerable path. These rules are starting points and must be tuned to each deployment's routing and caching model.

Sigma Rule

title: Next.js Cache Key Confusion - Cross Root-Param Content Reuse (CVE-2026-103004)
id: 6f2a1c74-9b3e-4d2a-9c11-7c0b1e2f5a90
status: experimental
description: >
  Detects application-log patterns consistent with CVE-2026-103004, where nested
  'use cache' functions reading next/root-params produce cache entries whose keys omit
  the root param, causing one root param value's content to be served for another.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-103004
author: valtersit.com
date: 2026/01/01
logsource:
  category: application
  product: nextjs
detection:
  selection_cache_components:
    - 'cacheComponents'
  selection_cache_key:
    - 'use cache'
    - 'root-params'
    - 'cache key'
  selection_mismatch:
    - 'cache hit'
    - 'revalidate'
    - 'prerender'
  condition: selection_cache_components and selection_cache_key and selection_mismatch
falsepositives:
  - Legitimate cache warm-up and revalidation logging
  - Development-mode verbose framework logging
level: medium
tags:
  - attack.t1190
  - cve.2026.103004
  - cwe.524

YARA Rule

rule CVE_2026_103004_NextJS_Cache_Key_Confusion
{
    meta:
        description = "Detects Next.js source/config artifacts referencing the vulnerable cache-components + root-params combination associated with CVE-2026-103004"
        author = "valtersit.com"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-103004"
        cve = "CVE-2026-103004"

    strings:
        $cc = "cacheComponents" ascii wide nocase
        $uc = "'use cache'" ascii wide nocase
        $uc2 = "\"use cache\"" ascii wide nocase
        $rp = "next/root-params" ascii wide nocase
        $rp2 = "root-params" ascii wide nocase

    condition:
        ($cc and ($uc or $uc2) and ($rp or $rp2))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-103004 Next.js Cache Components root-params cache-key confusion - repeated root-param cache probe"; flow:established,to_server; http.method; content:"GET"; http.header; content:"Accept"; pcre:"/(?i)(application\/(xhtml\+xml|json)|text\/x-component)/"; threshold:type both, track by_src, count 40, seconds 30; classtype:attempted-recon; reference:cve,2026-103004; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-103004; metadata:created_at 2026_01_01, updated_at 2026_01_01; sid:2026103004; rev:1;)

Note: because the defect requires no malicious payload, this rule targets high-frequency, rapid-fire requests to the same path with varying root-level segments — the behavioral footprint of an actor probing cache-key cardinality. Deployments should tune the threshold and path pattern to their routing scheme.

Elastic Detection

sequence by source.ip with maxspan=60s
  [ network where network.protocol == "http" and http.request.method == "GET" and
      http.response.status_code == 200 and url.path like "/*" ]
  [ network where network.protocol == "http" and http.request.method == "GET" and
      http.response.status_code == 200 and url.path like "/*" and
      http.response.bytes == 0 ]

Note: compare successive responses for identical cache markers (Age, X-Cache, ETag) across differing top-level path segments. Where the platform exposes rendered-response hashes, alert when byte-identical bodies are returned for distinct root-param values on cache-bearing paths.

Splunk SPL Query

index=web sourcetype=nextjs_access
| eval rootseg = mvindex(split(uri_path, "/"), 1)
| stats dc(rootseg) as distinct_roots,
        values(rootseg) as roots,
        count as req_count,
        dc(response_size) as distinct_sizes
        by clientip, uri_path, response_status
| where distinct_roots > 1 AND distinct_sizes < distinct_roots AND req_count > 20
| sort - req_count
| table clientip, uri_path, distinct_roots, distinct_sizes, req_count, roots

This surfaces clients hitting the same path across multiple top-level (root) segments while receiving an anomalously low number of distinct response sizes — a signature consistent with a mis-keyed cache serving one context's content to others.

Wazuh OSSEC Rule

<group name="nextjs,cve-2026-103004,">
  <rule id="1030040" level="6">
    <decoded_as>json</decoded_as>
    <field name="cacheComponents">true</field>
    <description>CVE-2026-103004: Next.js deployment running with cacheComponents enabled - verify version is patched (>=16.3.8)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>configuration,cache,</group>
  </rule>
  <rule id="1030041" level="10">
    <if_sid>1030040</if_sid>
    <field name="version">^16\.3\.[0-7]$</field>
    <description>CVE-2026-103004: Vulnerable Next.js version 16.3.0-16.3.7 detected with cacheComponents enabled - cache key confusion / cross root-param content disclosure risk</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>vulnerability,cache,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence is available from any tracked source in this dataset (Patch Sources: []). Vendor fix field is N/A and no vendor workaround is recorded. However, the NVD description itself states the issue "has been patched in 16.3.8", so upgrade guidance is provided on that basis while flagging that this content has not been corroborated by an independent vendor advisory in the supplied data.

1) Immediate mitigations (until upgrade):

• Determine exposure first: identify all Next.js deployments in the 16.3.0–16.3.7 range and confirm whether cacheComponents: true is set (cacheComponents / Cache Components enabled). Only those with Cache Components active are impacted by this specific defect.
• Review applications for the vulnerable structural pattern: 'use cache' functions that call other 'use cache' functions, where an inner function reads a root param via next/root-params and is invoked from an existing cache entry. Where feasible, break the nesting (e.g., ensure root-param reads occur in the outer keyed function, or avoid caching the outer function) to remove the mis-keying precondition.
• Audit and tighten cache headers on affected routes. The NVD description notes that "shared cache headers let downstream caches redistribute the content further." Reduce or remove shared/downstream cacheability (Cache-Control: private / disabling shared caches / purging CDN caches) on any root-param-scoped route until patched, and purge existing caches that may hold mis-keyed entries.
• Purge/rebuild existing cache artifacts, including build-time prerender output, since the description states the flaw applies to build-time prerendering as well.

2) Patch / upgrade steps:

• Upgrade to Next.js 16.3.8 (per NVD) or later. Pin the version explicitly in dependency manifests and lockfiles rather than using a floating range that could resolve inconsistently.
• Rebuild the application after upgrading so any build-time prerendered entries are regenerated with the corrected cache-key logic.
• Invalidate runtime and edge/CDN caches post-upgrade to evict entries written by the vulnerable version.
• Because this dataset carries no vendor advisory or patch source, validate the fix against the upstream Next.js release notes / security advisory for 16.3.8 before closing out, and monitor the record for an official CVSS score and any errata.

3) Long-term hardening:

• Treat cache keys as a security boundary: for any parameter that scopes content (tenants, regions, locale, permissions), verify it is an explicit part of the cache key rather than relying on implicit dynamic-value tracking.
• Maintain automated regression tests that assert distinct root-param values never receive byte-identical cached responses on sensitive routes.
• Enforce a version policy that promptly tracks Next.js security releases, and inventory all framework instances (including build-time tooling and any self-hosted renderers) so affected versions are detectable.
• Adopt defense-in-depth cache partitioning (per-tenant/regional cache namespaces where supported) so that a single key-construction defect cannot cross context boundaries.

References

• NVD — CVE-2026-103004: https://nvd.nist.gov/vuln/detail/CVE-2026-103004
• CWE-524 — Use of Cache Containing Sensitive Information: https://cwe.mitre.org/data/definitions/524.html
• MITRE ATT&CK — T1190 Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• Next.js project (verify 16.3.8 fix in upstream release notes/security advisory): https://github.com/vercel/next.js/releases
• CISA Known Exploited Vulnerabilities Catalog — verify current status (CVE-2026-103004 not listed at time of writing): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor / exploit-in-the-wild status: No known threat actor campaigns, no public PoC, and no CISA KEV listing are associated with CVE-2026-103004 in the available data. FIRST.org has not yet assigned an EPSS score.