Server-side Request Forgery (SSRF) Affecting @sveltejs/kit package, versions <3.0.0
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsSnyk Learn
Learn about Server-side Request Forgery (SSRF) vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-JS-SVELTEJSKIT-21347777
- published21 Oct 2026
- disclosed21 Oct 2026
- creditRich-Harris
Introduced: 21 Oct 2026
NewCVE-2026-114062 (opens in a new tab)How to fix?
Upgrade @sveltejs/kit to version 3.0.0 or higher.
Overview
@sveltejs/kit is a SvelteKit framework and CLI
Affected versions of this package are vulnerable to Server-side Request Forgery (SSRF) via server-side self-fetch fallbacks that automatically follow HTTP redirects. SvelteKit makes server-side fallback requests to URLs derived from the incoming request origin in several scenarios: 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 unresolvable from the server manifest. An attacker who can influence the request origin - for example by manipulating Host or forwarded host/protocol headers - can cause these fallback requests to reach an attacker-controlled server, which then redirects them to internal services.
Note: Exposure depends on the adapter and deployment configuration; for example, this is exploitable with adapter-node when the request origin is derived from unvalidated Host or forwarded host/protocol headers.
Workaround
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 allowed request hosts and supplies trusted host/protocol metadata, ensuring forwarded headers used to construct the request origin are not accepted directly from untrusted clients.