[HN Gopher] CVEs affecting the Svelte ecosystem
___________________________________________________________________
CVEs affecting the Svelte ecosystem
Author : tobr
Score : 127 points
Date : 2026-01-15 17:51 UTC (5 hours ago)
(HTM) web link (svelte.dev)
(TXT) w3m dump (svelte.dev)
| swyx wrote:
| 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
| chc4 wrote:
| SSRF is not just a DoS.
| CodesInChaos wrote:
| 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).
| staticassertion wrote:
| Yeah, that's less of a "vulnerability" and more of how I
| expect 99% of companies to handle authentication within a
| network (sadly).
| appplication wrote:
| 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.
| no_wizard wrote:
| 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?
| appplication wrote:
| 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.
| hsbauauvhabzb wrote:
| 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.
| dwattttt wrote:
| The phrase is typically analysis paralysis, but the image
| of a team of analysts frozen in fear is quite evocative.
| hsbauauvhabzb wrote:
| Autocorrected on my iPhone, but sometimes the best thing
| analysts could do is nothing ;)
| Agreed3750 wrote:
| hey react called, they want their vulnerabilities back
| Raed667 wrote:
| /s
| afavour wrote:
| https://apps.apple.com/ seems a little more involved than a
| demo app to me
| ChocolateGod wrote:
| Apple TV and Music also use Svelte.
| rafram wrote:
| Not to mention most interactive content from the New York
| Times (which is what Rich Harris originally developed it
| for).
| r14c wrote:
| Hey I work on an enterprise app that's written in svelte.
| There are dozens of us!
| tietjens wrote:
| Small sites such as IKEA and the New York Times are built
| with Svelte.
| Alupis wrote:
| Crates.io is moving to Svelte[1].
|
| [1] https://github.com/rust-lang/crates.io/issues/12515
| skeletal88 wrote:
| What did you want to achieve with this sarcastic comment?
| Make us use react, because it's users are as cool as you?
| Seattle3503 wrote:
| Do these impact static builds?
| khromov wrote:
| 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.
| rich_harris wrote:
| 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!
| lukax wrote:
| 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.
| phplovesong wrote:
| Pahap bros are killing it!
| epolanski wrote:
| I wish the reports included the PRs/commits pointing to the fix
| so I don't need to search it on my own.
___________________________________________________________________
(page generated 2026-01-15 23:00 UTC)