SvelteKit CVE-2026-114061

Exploitation requires a SvelteKit application (version before 3.0.0) that (1) uses prerendering for the affected page and (2) calls setHeaders to set a cache-control header whose value is derived from attacker-influenceable untrusted data available at prerender/build time. The injected payload only executes when a user later visits the prerendered page, so victim page visits (UI:P) are needed and the window of control is at prerender time, not at live request time. Limiting factors: applications that never set cache-control via setHeaders, that do not prerender, or that only use trusted/static header values are not exploitable; impact is confined to the user's browser context (no server compromise).

This is a genuinely low-priority issue, and the multiple signals agree rather than conflict. The vendor-supplied CVSS 4.0 vector scores only 2.3 (Low): AV:N and PR:N suggest network-reachable and unauthenticated, but AT:P (attack requirements present) and UI:P (passive user interaction) plus zero vulnerable-system impact (VC:N/VI:N/VA:N) and only low subsequent-system impact (SC:L/SI:L) reflect that this is a narrowly-conditioned reflected/stored XSS whose only impact is in the visiting user's browser. No EPSS score was provided in the input, no POC was referenced, and the CVE is not on CISA KEV - so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is further depressed by the precondition that a developer must feed attacker-influenced untrusted data into a cache-control header via setHeaders on a prerendered page, which is an uncommon pattern. Note the one apparent tension: PR:N/AV:N reads as 'remote unauthenticated,' yet the description makes clear exploitation depends on an attacker controlling an untrusted value at prerender (build) time, which is a meaningful real-world constraint not captured by the base vector - verify the data-flow assumption against your own application.

A SvelteKit application prerenders a page and calls setHeaders to set a cache-control value derived from untrusted input (e.g. CMS content or external data). At prerender time the attacker-influenced value breaks out of the content attribute of the <meta http-equiv="cache-control"> tag and injects HTML/JavaScript, which then executes in the browser of any user who later visits the prerendered page. No public exploit code was referenced in the input; exploitation requires an application that routes untrusted data into that header.