@sveltejs/kit: SSRF via redirects in server-side self-fetch fallbacks

Impact

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.

Patches

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.

Workarounds

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.