First off, love svelte, the team is really doing a good job focusing on developer ergonomics.
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.
I want to ask simply for curiosity. Knowing you felt this way about that code, and I'm assuming knew that it had some level of relative importance to Svelte as a whole, how did that inform your decision making, if at all?
My decision making to use svelte? TBH I looked at source only well after I was far enough along development to be committed to it as a framework.
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.
It’s probably comparable to other js frameworks, and auditing every package before you use them will leave you in analysis paralysis. I have a low opinion of software in general, but svelte isn’t a particular standout in that aspect.
Here's the one true answer to fit all use cases: every framework and language, every single last one of them, has some horrifying code buried somewhere. If you dig down into any piece of software far enough you'll find something insane and sketchy.
I consider it a small win that those are _only_ 'resource exhaustion' attacks. Denial of service potential to be sure. Something nice to avoid / have limits on also for sure.
However I'd rather have that than a more dire consequence.
all DoS attacks and one XSS. this isnt as bad as the react server components CVEs, which enabled RCE.
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
The blast radius is also limited by the fact 3/5 require remote functions to be enabled, which is still marked "experimental". Then 1 more uses hydratable, which is only relevant when using async mode, which is also behind an "experimental" flag.
To have a significant impact SSRF needs to be combined with a second worse vulnerability: An endpoint that trusts unauthenticated requests just because they come from within the local network. Sadly several popular clouds have such a vulnerability out of the box (metadata endpoint).
No, if you're using `adapter-static` (or, if not using SvelteKit at all, just not doing any dynamic server-rendering) then you are not affected. But upgrade anyway!
Great, I love sveltekit for SPA apps... I am just not using any SSR at all. I would like it would become more straightforward to use it that way. I would say that large amount of apps are better of as just SPAs. Internal dashboards, desktop like apps, etc...
Not from my reading. DoS are irrelevant, remote functions exploits don't apply and from my reading neither does the "XSS via hydratable" since a prerequisite is hydratable() which is a Remote Functions feature.
> 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 only you could learn lessons from the mistakes of others...
First off, love svelte, the team is really doing a good job focusing on developer ergonomics.
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.
I want to ask simply for curiosity. Knowing you felt this way about that code, and I'm assuming knew that it had some level of relative importance to Svelte as a whole, how did that inform your decision making, if at all?
My decision making to use svelte? TBH I looked at source only well after I was far enough along development to be committed to it as a framework.
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.
It’s probably comparable to other js frameworks, and auditing every package before you use them will leave you in analysis paralysis. I have a low opinion of software in general, but svelte isn’t a particular standout in that aspect.
The phrase is typically analysis paralysis, but the image of a team of analysts frozen in fear is quite evocative.
Autocorrected on my iPhone, but sometimes the best thing analysts could do is nothing ;)
Here's the one true answer to fit all use cases: every framework and language, every single last one of them, has some horrifying code buried somewhere. If you dig down into any piece of software far enough you'll find something insane and sketchy.
Yeah I have never been a fan of the devalue part of svelte.
It's not that simple to safely parse HTTP request form. Just look at Go security releases related to form parsing (a new fix released just today).
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.
I consider it a small win that those are _only_ 'resource exhaustion' attacks. Denial of service potential to be sure. Something nice to avoid / have limits on also for sure.
However I'd rather have that than a more dire consequence.
all DoS attacks and one XSS. this isnt as bad as the react server components CVEs, which enabled RCE.
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
The blast radius is also limited by the fact 3/5 require remote functions to be enabled, which is still marked "experimental". Then 1 more uses hydratable, which is only relevant when using async mode, which is also behind an "experimental" flag.
SSRF is not just a DoS.
To have a significant impact SSRF needs to be combined with a second worse vulnerability: An endpoint that trusts unauthenticated requests just because they come from within the local network. Sadly several popular clouds have such a vulnerability out of the box (metadata endpoint).
Yeah, that's less of a "vulnerability" and more of how I expect 99% of companies to handle authentication within a network (sadly).
Do these impact static builds?
No, if you're using `adapter-static` (or, if not using SvelteKit at all, just not doing any dynamic server-rendering) then you are not affected. But upgrade anyway!
Great, I love sveltekit for SPA apps... I am just not using any SSR at all. I would like it would become more straightforward to use it that way. I would say that large amount of apps are better of as just SPAs. Internal dashboards, desktop like apps, etc...
Not from my reading. DoS are irrelevant, remote functions exploits don't apply and from my reading neither does the "XSS via hydratable" since a prerequisite is hydratable() which is a Remote Functions feature.
I wish the reports included the PRs/commits pointing to the fix.
> 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 only you could learn lessons from the mistakes of others...
[flagged]
[flagged]
[flagged]
Small sites such as IKEA and the New York Times are built with Svelte.
Crates.io is moving to Svelte[1].
[1] https://github.com/rust-lang/crates.io/issues/12515
https://apps.apple.com/ seems a little more involved than a demo app to me
Not to mention most interactive content from the New York Times (which is what Rich Harris originally developed it for).
Apple TV and Music also use Svelte.
Hey I work on an enterprise app that's written in svelte. There are dozens of us!
What did you want to achieve with this sarcastic comment? Make us use react, because it's users are as cool as you?
[dead]