Skip to content
Security & Trust

SvelteKit bug lets an untrusted cache header inject code into pages

Only apps that prerender pages and copy cache headers from untrusted sources are exposed. The fix is version 3.0.0.

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
SvelteKit bug lets an untrusted cache header inject code into pages
In brief
  • GitHub's advisory says SvelteKit pages prerendered with an untrusted cache-control value can carry injected script, because the value is inserted without escaping.
  • Only apps that prerender pages and set cache-control through setHeaders from an untrusted source are affected. The advisory text reports no attacks.
  • Upgrade @sveltejs/kit to 3.0.0 or later, or use a fixed cache policy, and ask teams where their header values come from.

Most teams guard the places where customers type. Few treat a cache setting as something an attacker could write. A new SvelteKit advisory shows the gap in that habit. Any value that ends up inside a page is input, whatever it is called.

What the advisory says

GitHub's advisory database published the entry on October 23. It covers @sveltejs/kit, the application framework for Svelte. The advisory names two conditions for exposure. The app prerenders pages, and it passes a cache-control value into setHeaders from a source it cannot vouch for. Together, these allow cross-site scripting (XSS).

Prerendering means building pages ahead of time as finished files. XSS means an attacker's script runs in a visitor's browser as if the site had sent it.

The advisory links NVD entry CVE-2026-114061 and tells readers to upgrade to @sveltejs/kit 3.0.0 or later. VulnCheck's linked advisory is titled as covering SvelteKit before 3.0.0. The advisory text gives no severity score and reports no attacks in the wild.

How the flaw works

setHeaders lets developers set HTTP headers, the small instructions that travel with a web page. A cache-control header tells browsers and caches how long to keep a page.

On prerendered pages, SvelteKit writes this value into the page itself as a meta tag whose http-equiv setting is cache-control. The advisory says the framework inserted the value without escaping it. Escaping turns characters with special meaning in HTML into harmless text.

Think of the tag's content attribute as a quoted phrase. If the value contains a closing quote, the phrase ends early. Whatever follows is read as page code. The advisory says an attacker can end the attribute early and add HTML or JavaScript of their own.

Timing matters here. The attacker must influence the value at prerender time, when the page is generated. The generated page then carries the injected code, which the advisory says can run when users visit.

Why a header can slip past review

A cache-control header looks like plumbing. Review effort can go to forms, comments and search boxes, while a caching value gets less attention. Asking where such a value came from is easy to skip.

The lesson here is that trust belongs to where data came from, not to what it is called. If a value was copied from another system, it deserves the same suspicion as a form field. The advisory does not say which systems might supply such values.

This case also puts the weak point in the build step. Reviews can treat the build as internal ground. The advisory's prerender-time condition shows a value can cross into the output there.

How wide the exposure is

The conditions are narrow. A site needs both prerendered pages and an untrusted source for the cache-control value. An app that meets only one of these falls outside what the advisory describes.

What to ask your team

Start with inventory. Which applications use @sveltejs/kit, and which version? Which of them prerender pages and call setHeaders with a cache-control value?

Then ask where that value comes from. A fixed string in the code is the safe answer. A value copied from an outside system needs a closer look.

The patch makes SvelteKit escape the header value before writing it into the page. The advisory says to upgrade to @sveltejs/kit 3.0.0 or later. That is a new major version, so have the team read the linked release notes before scheduling the work.

Until your team has upgraded, the advisory suggests using a fixed, trusted cache policy rather than forwarding outside values. Teams can also check what other values their build step writes into generated pages.

The patch escapes one value. The habit worth building is asking where every value came from.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.

Share this insight