CVE-2025-67647: 
JavaScript vulnerability analysis and mitigation

CVE-2025-67647 is a Server-Side Request Forgery (SSRF) and Denial of Service (DoS) vulnerability in SvelteKit, a framework for building web applications using Svelte. Disclosed on January 15, 2026, it affects @sveltejs/kit versions 2.19.0 through 2.49.4 and @sveltejs/adapter-node versions 5.4.1 through 5.5.0. The vulnerability is triggered under specific conditions involving prerendered routes and misconfigured deployments. It carries a CVSS v3.1 base score of 9.1 (Critical) and a CVSS v4.0 base score of 8.4 (High) (GitHub Advisory).

The vulnerability stems from two distinct weaknesses: an Uncaught Exception (CWE-248) and Server-Side Request Forgery (CWE-918). In the DoS vector (affecting versions 2.44.0–2.49.4), when a prerendered route is requested, SvelteKit internally fetches the prerendered resource using a fetch() call constructed from attacker-controlled HTTP headers (e.g., Host). An unhandled exception during this fetch causes the server process to terminate. In the SSRF vector (affecting versions 2.19.0–2.49.4), when adapter-node is used without a configured ORIGIN environment variable and without a reverse proxy enforcing Host header validation, an attacker can manipulate the Host header to redirect the internal fetch to an arbitrary internal service. Additionally, an attacker-controlled server can inject XSS payloads via cache-control headers, enabling Stored XSS (SXSS) through CDN cache poisoning. The fix adds validation for protocol, host, and port headers in handler.js and corrects URL-decoded pathname comparison in respond.js (GitHub Advisory, Patch Commit).

Successful exploitation can result in three distinct impacts: (1) complete server process termination causing service unavailability (DoS), (2) unauthorized access to internal services reachable from SvelteKit's server runtime without authentication (SSRF), and (3) injection of malicious XSS payloads into CDN caches (SXSS via cache poisoning), which can affect all users who subsequently receive the poisoned cached content. The SSRF vector poses a risk of lateral movement to internal infrastructure, while the cache poisoning vector can compromise the integrity of content delivered to a broad user base (GitHub Advisory, Svelte Blog).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.041%, indicating a low current probability of exploitation. The vulnerability requires specific deployment conditions (prerendered routes, adapter-node without ORIGIN set, no Host-validating reverse proxy), which limits the attack surface but does not require authentication from the attacker.

1. Reconnaissance: Identify SvelteKit applications running @sveltejs/kit versions 2.19.0–2.49.4 with adapter-node (versions 5.4.1–5.5.0), no ORIGIN environment variable configured, and no reverse proxy enforcing Host header validation. Look for apps with at least one prerendered route (export const prerender = true).
2. Craft malicious Host header (DoS): Send an HTTP request to a prerendered route with a malformed or unreachable Host header value. SvelteKit will attempt an internal fetch() using this header to resolve the prerendered resource; the resulting unhandled exception terminates the server process.
3. Craft malicious Host header (SSRF): Send an HTTP request to a prerendered route with a Host header pointing to an internal service (e.g., Host: 169.254.169.254 for cloud metadata, or an internal API endpoint). SvelteKit constructs the fetch URL from this header and issues a server-side request to the attacker-specified target, potentially returning sensitive data.
4. Cache poisoning (SXSS): Control a server that SvelteKit fetches from (via the SSRF vector), and respond with a payload containing XSS content and permissive Cache-Control headers. A CDN caching the response will serve the malicious content to subsequent legitimate users. (GitHub Advisory, Patch Commit)

• Network: Unexpected outbound HTTP requests from the SvelteKit server process to internal IP ranges (e.g., RFC 1918 addresses, cloud metadata endpoints like 169.254.169.254) or to external attacker-controlled hosts.
• Network: Inbound HTTP requests to prerendered routes with anomalous or spoofed Host, X-Forwarded-Host, or protocol headers.
• Logs: Server access logs showing requests to prerendered routes with unusual Host header values not matching the application's configured domain.
• Logs: Node.js process crash logs or unhandled exception stack traces originating from the SvelteKit respond.js or handler.js modules, particularly around fetch() calls during prerender resolution.
• Logs: CDN or proxy logs showing responses with unexpected Cache-Control headers (e.g., public, max-age=...) for routes that should not be publicly cached, potentially indicating cache poisoning.
• Process: Unexpected termination and restart of the SvelteKit Node.js server process without a clear application-level cause.

The primary remediation is to upgrade @sveltejs/kit to version 2.49.5 and @sveltejs/adapter-node to version 5.5.1, both released on January 15, 2026 (kit@2.49.5 Release, adapter-node@5.5.1 Release). For deployments that cannot immediately upgrade, the following mitigations reduce exposure: (1) configure the ORIGIN environment variable in adapter-node to explicitly set the trusted origin, (2) deploy a reverse proxy (e.g., nginx, Caddy) that validates and strips untrusted Host headers before they reach SvelteKit, and (3) implement WAF rules to detect and block requests with anomalous Host header values. Network segmentation to restrict SvelteKit's outbound access to internal services is also recommended as a defense-in-depth measure (GitHub Advisory).

The Svelte team published an official blog post covering CVEs affecting the Svelte ecosystem, acknowledging the vulnerability and directing users to the GitHub Security Advisory (Svelte Blog). The vulnerability was credited to researchers Allam Rachid (zhero;), Allam Yasser (inzo), and d-xuan (wednesday), with remediation developed by teemingc and reviewed by benmccann (GitHub Advisory). The CVE appeared in community tracking threads on Reddit's r/CVEWatch as a top trending CVE in the days following disclosure, reflecting notable community interest given SvelteKit's widespread use in modern web development.