@SVELTEJS/KIT · GHSA-prjg-x2qj-wj3g · Package
FIX → >= 2.70.4
SvelteKit's server makes internal self-fetch requests to URLs built from the incoming request origin, and it followed HTTP redirects on those requests. An attacker who controls the origin and a server they host can redirect the server to internal services, reaching targets the attacker could not reach directly.
first public Oct 5, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications built on SvelteKit that run server-side code, most often with adapter-node, where the request origin is taken from unvalidated Host or forwarded headers. Exposure depends on the adapter and deployment; static or fully prerendered sites with no server fallbacks are unlikely to be affected.
Not affected if default-config, managed-hosting, static-export
Who cares adapter-node, node, self-hosted, svelte, sveltekit
npm ls @sveltejs/kitadapter-node and whether the origin comes from the Host or forwarded headers without validationpaths.origin is set in svelte.config.jsUpgrade to >= 2.70.4
In certain circumstances, SvelteKit makes server-side fallback requests to URLs derived from the incoming request origin. These self-fetches occur when retrieving prerendered data for experimental prerender remote functions, serving rerouted prerendered content, fetching static or prerendered resources without an internal read implementation, and handling same-origin subrequests that cannot be resolved from the server manifest (including during error-page rendering).
If an attacker can influence the request origin and trigger one of these fallback paths, SvelteKit can make a request to an attacker-controlled server. These requests previously followed HTTP redirects automatically, allowing that server to redirect the request to an internal service and cause server-side request forgery (SSRF).
Exposure depends on the adapter and deployment configuration. For example, this can occur with adapter-node when the request origin is derived from unvalidated Host or forwarded host/protocol headers.
Fixed in version 3.0.0.
The fix disables automatic redirect following for these framework self-fetch fallbacks. It prevents an attacker-controlled first response from causing further server-side requests through redirects; it does not validate or restrict the origin of the initial request.
Configure a trusted fixed request origin where supported. For adapter-node, set the paths.origin configuration to the application’s trusted origin. Alternatively, use a trusted reverse proxy that validates the allowed request hosts and supplies trusted host/protocol metadata. Forwarded headers used to construct the request origin must not be accepted directly from untrusted clients.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
@sveltejs/kit: move to 3.0.0 or later (affected up to 2.70.3, fixed from 2.70.4 per product data; advisory says fixed in 3.0.0)paths.origin to the trusted origin for adapter-node, or validate hosts at a trusted reverse proxy