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.

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

If only you could learn lessons from the mistakes of others...