Focus on svelte vulnerabilities and metrics.
Last updated: 08 Mar 2025, 23:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with svelte. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total svelte CVEs: 6
Earliest CVE date: 05 Apr 2021, 07:15 UTC
Latest CVE date: 30 Aug 2024, 17:15 UTC
Latest CVE reference: CVE-2024-45047
30-day Count (Rolling): 0
365-day Count (Rolling): 1
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): 0%
Year Variation (Calendar): -66.67%
Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): -66.67%
Average CVSS: 1.85
Max CVSS: 6.8
Critical CVEs (≥9): 0
Range | Count |
---|---|
0.0-3.9 | 4 |
4.0-6.9 | 2 |
7.0-8.9 | 0 |
9.0-10.0 | 0 |
These are the five CVEs with the highest CVSS scores for svelte, sorted by severity first and recency.
svelte performance oriented web framework. A potential mXSS vulnerability exists in Svelte for versions up to but not including 4.2.19. Svelte improperly escapes HTML on server-side rendering. 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, and a type of the XSS is known as mXSS (mutation XSS). More specifically, this can occur when injecting malicious content into an attribute within a `noscript` tag. This issue has been addressed in release version 4.2.19. Users are advised to upgrade. There are no known workarounds for this vulnerability.
SvelteKit is a web development kit. In SvelteKit 2, sending a GET request with a body eg `{}` to a built and previewed/hosted sveltekit app throws `Request with GET/HEAD method cannot have body.` and crashes the preview/hosting. After this happens, one must manually restart the app. `TRACE` requests will also cause the app to crash. Prerendered pages and SvelteKit 1 apps are not affected. `@sveltejs/adapter-node` versions 2.1.2, 3.0.3, and 4.0.1 and `@sveltejs/kit` version 2.4.3 contain a patch for this issue.
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 `is_form_content_type` 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.
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.
The unofficial Svelte extension before 104.8.0 for Visual Studio Code allows attackers to execute arbitrary code via a crafted workspace configuration.