That said, I’m not surprised to see a list of CVEs impacting devalue. After running into some (seemingly arbitrary) limitations, I skimmed the code and it definitely felt like there was some sketchiness to it, given how it handles user inputs. If I were nefarious or a security researcher it would definitely be a focal point for me.
If only you could learn lessons from the mistakes of others...
https://groups.google.com/g/golang-announce/search?q=form
5 fixes in 2 years related to HTTP form (url-encoded and multipart).
- Go 1.20.1 / 1.19.6: Multipart form parsing could consume excessive memory and disk (unbounded memory accounting and unlimited temp files)
- Go 1.20.3 / 1.19.8: Multipart form parsing could cause CPU and memory DoS due to undercounted memory usage and excessive allocations
- Go 1.20.3 / 1.19.8: HTTP and MIME header parsing could allocate far more memory than required from small inputs
- Go 1.22.1 / 1.21.8: Request.ParseMultipartForm did not properly limit memory usage when reading very long form lines, enabling memory exhaustion.
- Go 1.25.6 / 1.24.12: Request.ParseForm (URL-encoded forms) could allocate excessive memory when given very large numbers of key-value pairs.
Probably every HTTP server implementation in every language has similar vulnerabilities. And these are logic errors, not even memory safety bugs.
saving people a click:
CVE-2026-22775: DoS in devalue.parse due to memory/CPU exhaustion
> Effects: A malicious payload can cause arbitrarily large memory allocation, potentially crashing the process. SvelteKit applications using remote functions are vulnerable, as the parameters are run through devalue.parse If you don’t have remote functions enabled, SvelteKit is not vulnerable
CVE-2026-22774: DoS in devalue.parse due to memory exhaustion (Yes, this is very similar to the previous CVE. No, it is not the same!)
> Effects: A malicious payload can cause arbitrarily large memory allocation, potentially crashing the process SvelteKit applications using remote functions are vulnerable, as the parameters are run through devalue.parse If you don’t have remote functions enabled, SvelteKit is not vulnerable
CVE-2026-22803: Memory amplification DoS in Remote Functions binary form deserializer
> Effects: Users can submit a malicious request that causes your application to hang and allocate arbitrarily-large amounts of memory
CVE-2025-67647: Denial of service and possible SSRF when using prerendering
> Effects: DoS causes the server process to die SSRF allows access to internal resources that can be reached without authentication from SvelteKit’s server runtime If the stars align, it’s possible to obtain SXSS via cache poisoning by forcing a potential CDN to cache an XSS returned by the attacker’s server (the latter being able to specify the cache-control of their choice)
CVE-2025-15265: XSS via hydratable
> Effects: Your users are vulnerable to XSS if an attacker can manage to get a controlled key into hydratable that is then returned to another user
However I'd rather have that than a more dire consequence.
That said, I don’t have any regrets, it’s a pleasure to use svelte and I trust the team’s direction. This particular app is already locked down to internal/trusted users. For something more public or security critical it may warrant a deeper dive and more consideration.
We’ve released patches for 5 vulnerabilities across devalue, svelte, @sveltejs/kit, and @sveltejs/adapter-node. Here’s what you need to know:
If you’re using any of these packages, upgrade them to their corresponding non-vulnerable versions:
devalue: 5.6.2svelte: 5.46.4@sveltejs/kit: 2.49.5@sveltejs/adapter-node: 5.5.1For cross-dependent packages — svelte and @sveltejs/kit depend on devalue — patched versions already include upgraded dependencies.
We’re extremely thankful to all of the security researchers who responsibly disclosed these vulnerabilities and worked with us to get them fixed, to the security team at Vercel who helped us navigate the disclosure process, and to the maintainers who worked to publish the fixes.
Over the last few weeks, we've seen a spate of high profile vulnerabilities affecting popular tools across the web development ecosystem. While they are unfortunate, it has been encouraging to see the community pulling together to keep end users safe. Using the lessons learned from these vulnerabilities, we will invest in processes that will help catch future bugs during the writing and review phases, before they go live.
If you think you have discovered a vulnerability in a package maintained by the Svelte team, we urge you to privately report it via the Security tab on the repo in question (or the Svelte repo, if unsure).
Full reports are available in the published security advisories, but we’ve included a brief summary of each below.
devaluedevalue versions 5.1.0 through 5.6.1, anddevalue.parse(Yes, this is very similar to the previous CVE. No, it is not the same!)
devaluedevalue versions 5.3.0 through 5.6.1, anddevalue.parse@sveltejs/kit2.49.0 through 2.49.4, andexperimental.remoteFunctions flag, andform@sveltejs/kit@sveltejs/adapter-node@sveltejs/kit versions 2.44.0 through 2.49.4, and@sveltejs/kit versions 2.19.0 through 2.49.4, and@sveltejs/adapter-node without a configured ORIGIN environment variable, and you are not using a reverse proxy that implements Host header validationsveltesvelte versions 5.46.0 through 5.46.3, andhydratable, and you’re passing unsanitized, user-controlled strings in as keyshydratable that is then returned to another user