CVE-2026-71314

The MAX_VFOR_LENGTH cap of 100,000 in Vue 3 SSR is a throttle, not a remediation. Understand what this means before deciding your patch timeline. When v-for receives a prop exceeding 100K items, Vue does not reject the input or throw — it renders the first 100K items and silently truncates the rest. This is a data integrity violation for any client expecting complete iteration, and it's a DoS vector in disguise: 100K server-side renders still consume significant heap, and a sustained request stream will exhaust Node.js event loop workers before triggering OOM. Most SSR deployments monitor response-time anomalies or connection counts, not per-request render-loop depth, so this attack bypasses standard anomaly detection. The severity decision hinges on your deployment model. On bare-metal Node.js with a 4GB heap, 100K iterations per request may be tolerable under low concurrency. On serverless functions (Lambda, Vercel, Cloudflare Workers) with 512MB-1024MB memory budgets, you'll hit memory limits far sooner — the effective ceiling is not 100K but your memory-per-request allocation. Model the attacker's iteration cost against your deployment's actual headroom, not the generic 100K figure. The deeper problem is API contract failure. The v-for directive was designed for client-side contexts where the browser enforces natural bounds — a 100K-item loop freezes the UI and the user abandons it. SSR removes that enforcement entirely, and Vue provides no developer-facing signal when the cap engages. A developer who now writes `v-for="item in fetchUnboundedData()"` has the same problem, just shifted to 100K. The fix teaches nothing about safe iteration budgets for server rendering. Treat this as a complete DoS block if your SSR layer accepts arbitrary prop values from request input under tight memory constraints — patch immediately. Treat it as a reduced-severity memory abuse vector if you have generous heap headroom and can tolerate the truncation failure mode — patch in your next maintenance window. In either case, instrument your SSR layer to log or alert when render iteration approaches the cap, because Vue won't. The 'unauthenticated' qualifier in the CVE is misleading: in SSR, every render endpoint is effectively unauthenticated at the framework level; the attack surface is the prop-passing interface, not session state.

Reviewed through automated stages and approved by a human before publication.