SvelteKit CVE-2026-82256

The application must run @sveltejs/kit version 2.69.0 or earlier and must expose at least one form action endpoint reachable over the network. No authentication, session token, or special client-side state is required - the attacker needs only the ability to send HTTP POST requests to the form handler URL. No specific non-default configuration is necessary; form actions are a standard SvelteKit feature and enabled by default when the developer defines them. Exploitation is strictly limited to availability impact (process crash); there is no indication it enables code execution, data exfiltration, or privilege escalation. Applications placed behind a reverse proxy that enforces a request body size limit are protected even without patching.

The CVSS 4.0 score of 6.9 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N) reflects low availability impact to the vulnerable system, with zero confidentiality or integrity impact. The network-accessible, zero-prerequisites nature means any internet-exposed SvelteKit application using form actions is reachable by any attacker without credentials. However, real-world impact is bounded by process manager behavior: tools like PM2 or systemd typically auto-restart crashed Node processes within seconds, limiting outage to brief windows unless the attacker sustains a high request rate that overwhelms restart logic. No EPSS data was supplied in the input and the vulnerability does not appear in the CISA KEV catalog, indicating no confirmed widespread exploitation. On the SSVC automatable dimension, this flaw scores 'yes' - it requires no interaction and can be scripted trivially - which slightly elevates operational priority above the raw CVSS availability metric suggests. Overall this is a moderate-priority patch: urgent for publicly exposed applications without a reverse proxy enforcing body size limits, lower priority for internal-only or rate-limited deployments.

An unauthenticated attacker identifies a publicly reachable SvelteKit form action endpoint and sends a loop of HTTP POST requests each carrying an abnormally large body. With no payload size validation in place, the framework attempts to process each request, exhausting available Node.js heap memory and crashing the process. The attacker continues sending requests faster than the process manager can restart the application, sustaining a denial-of-service condition against legitimate users.