Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
19 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Applications using enhanced form actions (use:enhance) on routes that accept paths beginning with //, such as catch-all routes, may be vulnerable to an open redirect. Patches A fix has been prepared for @sveltejs/kit 3.0.0. Users should upgrade to 3.0.0 or later. The fix preserves leading double slashes in action paths without generating protocol-relative URLs, restricts non-redirect action navigation to the current origin, and includes the origin when comparing action locations with the current page. Workarounds Reject requests whose parsed URL pathname begins with // before route resolution, for example in a reverse proxy or a SvelteKit handle hook. Alternatively, disable navigation for non-redirect enhanced form results by supplying a custom submission callback: This applies non-redirect results to the current page instead of navigating to the action location.
Recommended action: Upgrade to 3.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Applications that prerender pages and use setHeaders to set a cache-control header from an untrusted source are vulnerable to cross-site scripting (XSS). SvelteKit inserts the header value into a <meta http-equiv="cache-control" tag without escaping it. An attacker who can influence this value at prerender time can break out of the content attribute and inject HTML or JavaScript into the generated page. The injected code can then execute when users visit the page. Patches The fix escapes the header value before inserting it into the generated HTML. Upgrade to @sveltejs/kit version 3.0.0 or later. Workarounds Avoid forwarding untrusted cache-control header values with setHeaders on prerendered pages. Use a fixed, trusted cache policy instead.
Recommended action: Upgrade to 3.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact SvelteKit is vulnerable to remote CPU-exhaustion DoS attacks via specifically-crafted Accept headers. The impact is mitigated by default header length limits on most platforms, but in the case of raised or absent limits a denial of service is possible. Patches The vulnerability is patched in @sveltejs/kit version 2.70.2.
Recommended action: Upgrade to 2.70.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If you use remote form functions, have an input field of type file, and accept arbitrary user-controlled path names for the field, then you are vulnerable to a prototype pollution attack where the attacker can remove e.g. methods on the prototype.
Recommended action: Upgrade to 2.69.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Big remote form function payloads can cause the Node process to crash. Doing this repeatedly can cause DoS.
Recommended action: Upgrade to 2.69.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
query.batch() could, under very rare and specific timings, cause concurrent requests from different users to merge and resolve under single request context, enabling cross-user data disclosure.
Recommended action: Upgrade to 2.60.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.57.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.57.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Some relatively small inputs can cause very large files arrays in form handlers. If the SvelteKit application code doesn't check files.length or individual files' sizes and performs expensive processing with them, it can result in Denial of Service. Only users with experimental.remoteFunctions: true who are using the form function and are processing the files array without validation are vulnerable.
Recommended action: Upgrade to 2.53.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of @sveltejs/kit prior to 2.52.2 with remote functions enabled are vulnerable to CPU exhaustion. Malformed form data can cause the server to become unresponsive while processing a request, resulting in denial of service. Only applications using both experimental.remoteFunctions and form are vulnerable.
Recommended action: Upgrade to 2.52.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of @sveltejs/kit prior to 2.52.2 with remote functions enabled can be vulnerable to memory exhaustion. Malformed form data can cause the server process to crash due to excessive memory allocation, resulting in denial of service. Only applications using both experimental.remoteFunctions and form are vulnerable.
Recommended action: Upgrade to 2.52.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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:…
Recommended action: Upgrade to 2.49.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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).…
Recommended action: Upgrade to 2.49.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unsanitized search param names cause XSS vulnerability. You are affected if you iterate over all entries of event.url.searchParams inside a server load function. Attackers can exploit it by crafting a malicious URL and getting a user to click a link with said URL. Details SvelteKit tracks which parameters in event.url.searchParams are read inside server load functions. If the application iterates over the these parameters, the uses.searchparams array included in the boot script (embedded in the server-rendered HTML) will have any search param name included in unsanitized form. packages/kit/src/runtime/server/utils.js:150 has the stringifyuses(node) function which prints these out. Reproduction In a +page.server.js or +layout.server.js: If a user visits the page in question via a link containing ?</script/<scriptwindow.pwned%3D1</script/, the </script will be included verbatim in the payload, causing the embedded script to be executed. It is not necessary to return the…
Recommended action: Upgrade to 2.20.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
"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…
Recommended action: Upgrade to 2.8.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 2.8.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. 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
Recommended action: Upgrade to 2.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 by simply specifying an upper-cased Content-Type header value. The browser will not send uppercase characters on form submission, but this check does not block all expected cross-site requests: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simplerequests Details The CSRF protection is implemented using the code shown below. If the incoming request specifies a POST/PUT/PATCH/DELETE method, the protection will compare the server’s origin with the value of the HTTP Origin header. A mismatch between these values signals that…
Recommended action: Upgrade to 1.15.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 it’s users. The protection is implemented at kit/src/runtime/server/respond.js#L52. While the implementation does a sufficient job in mitigating common CSRF attacks, the protection can be bypassed by simply specifying a different Content-Type header value. Details The CSRF protection is implemented using the code shown below. If the incoming request specifies a POST method (1), the protection will compare the server’s origin with the value of the HTTP Origin header (2). A mismatch between these values signals that a potential attack has been detected. The final check is performed on the request’s Content-Type header (3) whether the value is either application/x-www-form-urlencoded or multipart/form-data…
Recommended action: Upgrade to 1.15.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.