Ecommerce Template CVE-2026-91154

Exploitable only when the deployed instance runs the vulnerable code (before commit ec97209) with Next.js cacheComponents enabled so storefront pages are served from 'use cache' entries tagged 'products' with an hours-long cacheLife - this is the condition that turns cache invalidation into meaningful availability impact. Additionally, the revalidateProducts action must be reachable: it becomes so because src/components/admin client components import it, forcing its Server Action id into a public /_next/static chunk, while the admin middleware in proxy.ts fails to gate the action endpoint. No authentication, user interaction, or special privileges are required (PR:N/UI:N); the practical limiter is that this is a self-hosted open-source template, so exposure depends on how each operator configured caching and middleware.

This is a genuine but strictly availability-scoped issue, not a high-severity emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N with VC:N/VI:N/VA:L) is internally consistent with the description: fully remote and unauthenticated with no complexity barriers, but the only impact is low availability degradation - no confidentiality or integrity loss. There is no EPSS score, no CISA KEV listing, and no public exploit code identified; the only references are the vendor patch commit and the reporter's advisory. SSVC-wise, exploitation is technically automatable (a trivial repeatable POST loop) but technical impact is 'partial' at best (cache denial forcing DB reads, not full service takedown), so this rates as track/act-later rather than a priority. The dominant risk-limiting factor is prevalence, not the vulnerability class: this is an open-source Next.js ecommerce starter template, so real-world blast radius depends entirely on how many derived deployments enabled cacheComponents and left the action ungated. Net: real but low-priority; the 6.9 base score overstates urgency because it does not weight the near-zero deployment footprint of the affected product.

An unauthenticated attacker loads the storefront, extracts the compiled Server Action id for revalidateProducts from a public /_next/static JavaScript chunk, then repeatedly POSTs that action id directly to the site. Each call invalidates the 'products' cache tag, keeping the cacheComponents cache permanently cold so every visitor request falls through to Postgres, degrading storefront performance and availability at near-zero attacker cost. No public exploit code was identified at time of analysis, though the technique is fully described in the advisory.