SvelteKit CVE-2026-114062

Exploitation requires that the SvelteKit application relies on server-side self-fetch fallbacks (the framework's internal fetch used during SSR when resolving its own endpoints) and that the attacker can influence the Host or forwarded (X-Forwarded-Host/-Proto) headers reaching the server - commonly possible when the app sits behind a misconfigured or trusting reverse proxy that does not pin/validate these headers. The automatic following of HTTP redirects by the fallback fetch is the core enabler. Limiting factors: realistic impact depends on which internal services are network-reachable from the SvelteKit host (e.g., cloud metadata, internal APIs); deployments that strip/validate inbound Host/forwarded headers at the proxy, or that do not use self-fetch fallbacks, are not exposed. Affects all versions below 3.0.0; upgrading to 3.0.0 remediates.

This is a medium-severity SSRF (CWE-918) with a mixed signal profile. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated attack, which is the most concerning part of the profile, but the impact is deliberately narrow: only VC:L (low confidentiality) with no integrity or availability impact, yielding a base score of 6.9 (Medium). No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no public exploit identified at time of analysis and no evidence of active exploitation - this is a defense-in-depth/patch-on-schedule issue rather than an emergency. Note a tension worth verifying: SSRF that reaches internal services typically implies a scope change and potentially higher downstream impact than VC:L alone suggests, yet the vendor scored subsequent-system impact as N; real-world severity depends on what internal services are reachable from the SvelteKit host. Overall: a legitimate, patchable medium-risk flaw driven by its unauthenticated network vector, not a high-priority emergency given absent exploitation signals and constrained impact.

An attacker sends requests to a SvelteKit application with manipulated Host or X-Forwarded-* headers so that the server's self-fetch fallback targets an attacker-controlled server. The attacker's server returns an HTTP redirect, which the SvelteKit server follows automatically, causing it to issue requests to internal-only services (e.g., cloud metadata endpoints or internal APIs) on the attacker's behalf. No public exploit code is identified at time of analysis, but the attack requires no authentication or user interaction (PR:N/UI:N).