Summary

Versions of SvelteKit are vulnerable to a server side request forgery (SSRF) and denial of service (DoS) under certain conditions.

Details

Affected versions from 2.44.0 onwards are vulnerable to DoS if:

- your app has at least one prerendered route (export const prerender = true)

Affected versions from 2.19.0 onwards are vulnerable to DoS and SSRF if:

- your app has at least one prerendered route (export const prerender = true) - AND you are using adapter-node without a configured ORIGIN environment variable, and you are not using a reverse proxy that implements Host header validation

Impact

The DoS causes the running server process to end.

The SSRF allows access to internal services that can be reached without authentication when fetched from SvelteKit's server runtime.

It is also possible to obtain an 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).

Credits - Allam Rachid (zhero;) - Allam Yasser (inzo) - d-xuan (wednesday)

The SvelteKit framework offers developers an option to create simple REST APIs. This is done by defining a +server.js file, containing endpoint handlers for different HTTP methods.

SvelteKit provides out-of-the-box cross-site request forgery (CSRF) protection to its users. The protection is implemented at kit/src/runtime/server/respond.js. While the implementation does a sufficient job of mitigating common CSRF attacks, the protection can be bypassed in versions prior to 1.15.2 by simply specifying an upper-cased Content-Type header value. The browser will not send uppercase characters, but this check does not block all expected CORS requests.

If abused, this issue will allow malicious requests to be submitted from third-party domains, which can allow execution of operations within the context of the victim's session, and in extreme scenarios can lead to unauthorized access to users’ accounts. This may lead to all POST operations requiring authentication being allowed in the following cases: If the target site sets SameSite=None on its auth cookie and the user visits a malicious site in a Chromium-based browser; if the target site doesn't set the SameSite attribute explicitly and the user visits a malicious site with Firefox/Safari with tracking protections turned off; and/or if the user is visiting a malicious site with a very outdated browser.

SvelteKit 1.15.2 contains a patch for this issue. It is also recommended to explicitly set SameSite to a value other than None on authentication cookies especially if the upgrade cannot be done in a timely manner.

SvelteKit is a web development framework. The SvelteKit framework offers developers an option to create simple REST APIs. This is done by defining a +server.js file, containing endpoint handlers for different HTTP methods.

SvelteKit provides out-of-the-box cross-site request forgery (CSRF) protection to its users. While the implementation does a sufficient job in mitigating common CSRF attacks, prior to version 1.15.1, the protection can be bypassed by simply specifying a different Content-Type header value.

If abused, this issue will allow malicious requests to be submitted from third-party domains, which can allow execution of operations within the context of the victim's session, and in extreme scenarios can lead to unauthorized access to users’ accounts.

SvelteKit 1.15.1 updates the isformcontenttype function call in the CSRF protection logic to include text/plain. As additional hardening of the CSRF protection mechanism against potential method overrides, SvelteKit 1.15.1 is now performing validation on PUT, PATCH and DELETE methods as well. This latter hardening is only needed to protect users who have put in some sort of ?method= override feature themselves in their handle hook, so that the request that resolve sees could be PUT/PATCH/DELETE when the browser issues a POST request.

SvelteKit versions from 2.49.0 through 2.53.2 (fixed in 2.53.3) contain a deserialization expansion issue in the experimental form remote function. When an application enables experimental.remoteFunctions and uses the form function to process the files array without validating files.length or individual file sizes, an attacker can submit relatively small inputs that expand into very large file arrays, leading to expensive processing and denial of service.

Summary

The experimental form remote function uses a binary data format containing a representation of submitted form data. A specially-crafted payload can cause the server to allocate a large amount of memory, causing DoS via memory exhaustion.

Details

When a form is submitted to a remote function endpoint, the SvelteKit client encodes the data using a custom format, and POSTs it to the endpoint as a request with an application/x-sveltekit-formdata content type.

The first few bytes of the request body encode the length of the data. SvelteKit will attempt to read the request body up until the specified offset, but if the body is not yet available then an array buffer of that size will be created eagerly to accommodate it as it arrives.

An attacker can force this code path by sending a small payload that specifies a large data length, then stalling the connection. The resulting array buffer will be held in memory, potentially causing memory exhaustion.

Impact

- Vulnerability type: Availability / memory exhaustion (memory amplification). - Who is impacted: SvelteKit apps with experimental.remoteFunctions enabled, and that expose a reachable Remote Form endpoint. - Attack: an unauthenticated attacker can repeatedly open connections, send only the 8-byte header/prefix (with large datalength), and stall the body to hold large allocations, exhausting memory.

SvelteKit is a framework for rapidly developing robust, performant web applications using Svelte. Prior to 2.57.1, under certain circumstances, requests could bypass the BODYSIZELIMIT on SvelteKit applications running with adapter-node. This bypass does not affect body size limits at other layers of the application stack, so limits enforced in the WAF, gateway, or at the platform level are unaffected. This vulnerability is fixed in 2.57.1.

1. devalue.parse allows proto to be set

A string passed to devalue.parse could represent an object with a proto property, which would assign a prototype to an object while allowing properties to be overwritten:

js class Vector { constructor(x, y) { this.x = x; this.y = y; }

get magnitude() { return (this.x 2 + this.y 2) 0.5; } }

const payload = [{"x":1,"y":2,"magnitude":3,"proto":4},3,4,"nope",["Vector",5],[6,7],8,9];

const vector = devalue.parse(payload, { Vector: ([x, y]) => new Vector(x, y) });

console.log("Is vector", vector instanceof Vector); // true console.log(vector.x) // 3 console.log(vector.y) // 4 console.log(vector.magnitude); // "nope" instead of 5

2. devalue.parse allows array prototype methods to be assigned to object

In a payload constructed with devalue.stringify, values are represented as array indices, where the array contains the 'hydrated' values:

js devalue.stringify({ message: 'hello' }); // [{"message":1},"hello"]

devalue.parse does not check that an index is numeric, which means that it could assign an array prototype method to a property instead:

js const object = devalue.parse('[{"toString":"push"}]'); object.toString(); // 0

This could be used by a creative attacker to bypass server-side validation.

The unofficial Svelte extension before 104.8.0 for Visual Studio Code allows attackers to execute arbitrary code via a crafted workspace configuration.

Summary In SvelteKit 2 sending a GET request with a body eg {} to a SvelteKit app in preview or with adapter-node throws Request with GET/HEAD method cannot have body. and crashes the app.

node:internal/deps/undici/undici:6066 throw new TypeError("Request with GET/HEAD method cannot have body."); ^

TypeError: Request with GET/HEAD method cannot have body. at new Request (node:internal/deps/undici/undici:6066:17) at getRequest (file:///C:/Users/admin/Desktop/reproduction/nodemodules/@sveltejs/kit/src/exports/node/index.js:107:9) at file:///C:/Users/admin/Desktop/reproduction/nodemodules/@sveltejs/kit/src/exports/vite/preview/index.js:181:26 at call (file:///C:/Users/admin/Desktop/reproduction/nodemodules/vite/dist/node/chunks/dep-9A4-l-43.js:44795:7) at next (file:///C:/Users/admin/Desktop/reproduction/nodemodules/vite/dist/node/chunks/dep-9A4-l-43.js:44739:5) at file:///C:/Users/admin/Desktop/reproduction/nodemodules/@sveltejs/kit/src/exports/vite/preview/index.js:172:6 at call (file:///C:/Users/admin/Desktop/reproduction/nodemodules/vite/dist/node/chunks/dep-9A4-l-43.js:44795:7) at next (file:///C:/Users/admin/Desktop/reproduction/nodemodules/vite/dist/node/chunks/dep-9A4-l-43.js:44739:5) at file:///C:/Users/admin/Desktop/reproduction/nodemodules/@sveltejs/kit/src/exports/vite/preview/index.js:211:27 at call (file:///C:/Users/admin/Desktop/reproduction/nodemodules/vite/dist/node/chunks/dep-9A4-l-43.js:44795:7)

Node.js v20.11.0

TRACE requests will also cause the app to crash. Prerendered pages and SvelteKit 1 apps are not affected.

<!-- Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer. --> PoC <!-- Complete instructions, including specific configuration details, to reproduce the vulnerability. --> First do a fresh install of SvelteKit 2 with the example app. Typescript.

1. npm run build 2. npm run preview 3. Go to http://localhost:4173 (works) 4. curl -X GET -d "{}" http://localhost:4173/bye 5. Application crashes and http://localhost:4173 is down

Impact <!-- What kind of vulnerability is it? Who is impacted? --> Denial of Service for apps using adapter-node

Summary

Certain inputs can cause devalue.parse to consume excessive CPU time and/or memory, potentially leading to denial of service in systems that parse input from untrusted sources. This affects applications using devalue.parse on externally-supplied data. The root cause is the typed array hydration expecting an ArrayBuffer as input, but not checking the assumption before creating the typed array.

Details

The parser's typed array hydration logic does not properly validate input before processing. Specially crafted inputs can cause disproportionate memory allocation or CPU usage on the receiving system.

Impact

This is a denial of service vulnerability affecting systems that use devalue.parse to handle data from potentially untrusted sources.

Affected systems should upgrade to patched versions immediately.

Summary

Certain inputs can cause devalue.parse to consume excessive CPU time and/or memory, potentially leading to denial of service in systems that parse input from untrusted sources. This affects applications using devalue.parse on externally-supplied data. The root cause is the ArrayBuffer hydration expecting base64 encoded strings as input, but not checking the assumption before decoding the input.

Details

The parser's ArrayBuffer hydration logic does not properly validate input before processing. Specially crafted inputs can cause disproportionate memory allocation or CPU usage on the receiving system.

Impact

This is a denial of service vulnerability affecting systems that use devalue.parse to handle data from potentially untrusted sources.

Affected systems should upgrade to patched versions immediately.

In devalue v5.6.3, devalue.parse and devalue.unflatten were susceptible to prototype pollution via maliciously crafted payloads. Successful exploitation could lead to Denial of Service (DoS) or type confusion.

devalue.parse could, due to quirks in some JavaScript engines, be convinced to allocate much more memory than was needed when deserializing sparse arrays, leading to excessive memory consumption.

Svelte is a performance oriented web framework. Prior to version 5.55.7, Svelte was vulnerable to DOM clobbering of its internal framework state on elements, potentially leading to XSS attacks. This issue has been patched in version 5.55.7.

In server-side rendering, attribute spreading on elements (e.g. <div {...attrs}>) enumerates inherited properties from the object's prototype chain rather than only own properties. In environments where Object.prototype has already been polluted — a precondition outside of Svelte's control — this can cause unexpected attributes to appear in SSR output or cause SSR to throw errors. Client-side rendering is not affected.

redirect, when called from inside the handle server hook with a location parameter containing characters that are invalid in a HTTP header, will cause an unhandled TypeError. This could result in DoS on some platforms, especially if the location passed to redirect contains unsanitized user input.

Summary

A potential XSS vulnerability exists in Svelte for versions prior to 4.2.19.

Details

Svelte improperly escapes HTML on server-side rendering. It converts strings according to the following rules:

- If the string is an attribute value: - " -> &quot; - & -> &amp; - Other characters -> No conversion - Otherwise: - < -> &lt; - & -> &amp; - Other characters -> No conversion

The assumption is that attributes will always stay as such, but in some situation the final DOM tree rendered on browsers is different from what Svelte expects on server-side rendering. This may be leveraged to perform XSS attacks. More specifically, this can occur when injecting malicious content into an attribute within a <noscript> tag.

PoC

A vulnerable page (+page.svelte): html <script> import { page } from "$app/stores"

// user input let href = $page.url.searchParams.get("href") ?? "https://example.com"; </script>

<noscript> <a href={href}>test</a> </noscript>

If a user accesses the following URL, http://localhost:4173/?href=</noscript><script>alert(123)</script> then, alert(123) will be executed.

Impact

XSS, when using an attribute within a noscript tag

The package svelte before 3.49.0 are vulnerable to Cross-site Scripting (XSS) due to improper input sanitization and to improper escape of attributes when using objects during SSR (Server-Side Rendering). Exploiting this vulnerability is possible via objects with a custom toString() function.

Summary

An XSS vulnerability exists in Svelte 5.46.0-2 resulting from improper escaping of hydratable keys. If these keys incorporate untrusted user input, arbitrary JavaScript can be injected into server-rendered HTML.

Details

When using the hydratable function, the first argument is used as a key to uniquely identify the data, such that the value is not regenerated in the browser.

This key is embedded into a <script> block in the server-rendered <head> without escaping unsafe characters. A malicious key can break out of the script context and inject arbitrary JavaScript into the HTML response.

Impact

This is a cross-site scripting vulnerability affecting applications that have the experimental.async flag enabled and use hydratable with keys incorporating untrusted user input.

- Impact: Arbitrary JS execution in the client’s browser. - Exploitability: Remote, single-request if key is attacker-controlled. - Typical Outcomes: - Session/token theft - DOM defacement - CSRF bypass via injected JS - Account takeover depending on cookie/session strategy

Affected applications should upgrade to a patched version immediately.

Svelte performance oriented web framework. Prior to version 5.53.5, the contents of bind:innerText and bind:textContent on contenteditable elements were not properly escaped. This could enable HTML injection and Cross-Site Scripting (XSS) if rendering untrusted data as the binding's initial value on the server. Version 5.53.5 fixes the issue.

An internal regex in the Svelte runtime can take exponential time to test in <svelte:element this={tag}></svelte:element>. You are only vulnerable to this if you allow tags of unconstrained length. If your application only allows a predetermined list of tags or trims their length before passing them to svelte:element, you are safe.

Summary

The static error.html template for errors contains placeholders that are replaced without escaping the content first.

Details

From https://kit.svelte.dev/docs/errors:

error.html is the page that is rendered when everything else fails. It can contain the following placeholders: %sveltekit.status% — the HTTP status %sveltekit.error.message% — the error message

This leads to possible injection if an app explicitly creates an error with a message that contains user controlled content that ends up being something like this inside a server handle function: js error(500, '<script>alert("boom")</script>'); Uncaught errors cannot be exploited like this, as they always render the message "Internal error".

Escaping the message string in the function that creates the html output can be done to improve safety for applications that are using custom errors on the server.

PoC

None provided

Impact

Only applications where user provided input is used in the Error message will be vulnerable, so the vast majority of applications will not be vulnerable

Summary

"Unsanitized input from the request URL flows into end, where it is used to render an HTML page returned to the user. This may result in a Cross-Site Scripting attack (XSS)."

Details

Source of potentially tainted data is in packages/kit/src/exports/vite/dev/index.js, line 437. This potentially tainted data is passed through a number of steps (which I could detail if you'd like) all the way down to line 91 in packages/kit/src/exports/vite/utils.js, which performs an operation that Snyk believes an attacker shouldn't be allowed to manipulate.

Another source of potentially tainted data (according to Snyk) comes from ‎packages/kit/src/exports/vite/utils.js, line 30, col 30 (i.e., the url property of req). This potentially tainted data is passed through a number of steps (which I could detail if you'd like) all the way down line 91 in packages/kit/src/exports/vite/utils.js, which performs an operation that Snyk believes an attacker shouldn't be allowed to manipulate.

PoC

Not provided

Impact

Little to none. The Vite development is not exposed to the network by default. And even if someone were able to trick a developer into executing an XSS against themselves, a development database should not have any sensitive data.

In certain circumstances, the server-side rendering output of an <option> element does not properly escape its content, potentially allowing HTML injection in the SSR output. Client-side rendering is not affected.

svelte performance oriented web framework. Versions of svelte prior to 5.51.5 are vulnerable to cross-site scripting (XSS) during server-side rendering. When using spread syntax to render attributes from untrusted data, event handler properties are included in the rendered HTML output. If an application spreads user-controlled or external data as element attributes, an attacker can inject malicious event handlers that execute in victims' browsers. This vulnerability is fixed in 5.51.5.

svelte performance oriented web framework. Prior to 5.51.5, when using <svelte:element this={tag}> in server-side rendering, the provided tag name is not validated or sanitized before being emitted into the HTML output. If the tag string contains unexpected characters, it can result in HTML injection in the SSR output. Client-side rendering is not affected. This vulnerability is fixed in 5.51.5.

Errors from transformError were not correctly escaped prior to being embedded in the HTML output, causing potential HTML injection and XSS if attacker-controlled content is returned from transformError.

Svelte is a performance oriented web framework. Prior to version 5.55.7, Svelte was vulnerable to DOM clobbering of its internal framework state on elements, potentially leading to XSS attacks. This issue has been patched in version 5.55.7.

SvelteKit versions before 2.69.1 contain a prototype pollution vulnerability in remote form functions with file input fields that accept arbitrary user-controlled path names. Attackers can manipulate the deletion path to remove methods on the prototype, potentially disabling application functionality.

Svelte is a performance oriented web framework. Prior to version 5.55.7, when using spread syntax to render attributes from untrusted data, event handler properties are included in the rendered HTML output. If an application spreads user-controlled or external data as element attributes, an attacker can inject malicious event handlers that execute in victims' browsers. Note that this vulnerability only triggers if the user's browser has JavaScript enabled but Svelte's hydration mechanism does not reach the vulnerable element before the event fires. This issue has been patched in version 5.55.7.