Five vulnerabilities hit Svelte and SvelteKit, update now

I had just started using Svelte when news of vulnerabilities came in. In January 2026, the Svelte official blog disclosed five CVEs at once. Since they include severe DoS, SSRF, and XSS issues, I wanted to summarize them together.

Impact Summary

CVE	Target	Type	Severity	Fixed Version
CVE-2026-22775	devalue	DoS (CPU / memory exhaustion)	High (7.5)	5.6.2
CVE-2026-22774	devalue	DoS (memory exhaustion)	High (7.5)	5.6.2
CVE-2026-22803	@sveltejs/kit	DoS (memory amplification)	High (8.2)	2.49.5
CVE-2025-67647	@sveltejs/kit	DoS / SSRF	High	2.49.5
CVE-2025-15265	svelte	XSS	Medium (5.3)	5.46.4

CVE-2026-22775: CPU and memory exhaustion in `devalue.parse`

Affected versions: devalue 5.1.0 to 5.6.1

The ArrayBuffer hydration path expects a Base64-encoded string, but the input is not validated before decoding. A malicious input can make devalue.parse consume excessive CPU time or memory and bring down the server.

This affects cases where SvelteKit Remote Functions or similar features parse user input.

GHSA: GHSA-g2pg-6438-jwpf

CVE-2026-22774: memory exhaustion in `devalue.parse`

Affected versions: devalue 5.3.0 to 5.6.1

Like CVE-2026-22775, this is caused by insufficient input validation in devalue.parse. Certain inputs can trigger memory exhaustion. The issue requires no authentication and no user interaction, and can be exploited over the network.

GHSA: GHSA-vw5p-8cq8-m7mv

CVE-2026-22803: memory amplification DoS in SvelteKit Remote Functions

Affected versions: @sveltejs/kit 2.49.0 to 2.49.4

When submitting a form to a Remote Function endpoint, the SvelteKit client sends the data in application/x-sveltekit-formdata format. The first few bytes of the request body specify the data length, and SvelteKit allocates an ArrayBuffer of that length in advance.

An attacker can send a tiny payload that declares a huge data length and then stop the connection, exhausting server memory.

This only affects apps with experimental.remoteFunctions enabled.

GHSA: GHSA-j2f3-wq62-6q46

CVE-2025-67647: DoS in prerender, SSRF under certain conditions

Affected versions:

DoS: @sveltejs/kit 2.44.0 to 2.49.4, when one or more prerendered routes exist
SSRF: @sveltejs/kit 2.19.0 to 2.49.4, when using adapter-node, ORIGIN is not set, and the reverse proxy does not validate the Host header

This stems from insufficient validation when constructing the origin. A single request can crash the server.

In addition, spoofing the Host header can lead to SSRF from the SvelteKit server to internal services. Because the Fetch API follows HTTP redirects automatically by default, an attacker can place an intermediate server that returns a 302 redirect and turn it into SSRF to an arbitrary path.

If you are using adapter-node, make sure to set the ORIGIN environment variable.

GHSA: GHSA-j62c-4x62-9r35

Technical details: Avoiding the paradox: A native full read SSRF and oneshot DoS in SvelteKit

CVE-2025-15265: XSS in hydration

Affected versions: svelte 5.46.0 to 5.46.3

This issue occurs when using the hydratable function, especially with experimental.async enabled. The first argument to hydratable (the key) is embedded directly into a <script> block inside the server-rendered <head>, but unsafe characters are not properly escaped.

If that key contains untrusted user input, an attacker can craft input that escapes the script context and inject arbitrary JavaScript. That could lead to session theft or account takeover.

GHSA: GHSA-6738-r8g5-qwp3

What to do

Do this now

# Update devalue
npm update devalue
# or
pnpm update devalue

# Update SvelteKit
npm update @sveltejs/kit
# or
pnpm update @sveltejs/kit

# Update Svelte
npm update svelte
# or
pnpm update svelte

Fixed versions:

devalue: 5.6.2 or later (5.7.0 recommended)
@sveltejs/kit: 2.49.5 or later
svelte: 5.46.4 or later

If you cannot update yet

Do not process untrusted data with devalue.parse
Disable experimental.remoteFunctions
Set the ORIGIN environment variable when using adapter-node
Use a reverse proxy that validates the Host header
Do not use user input for the hydratable key