Svelte 3.29.4 is a minor update to the Svelte JavaScript framework, building upon version 3.29.3. Both aim to provide developers with a cybernetically enhanced approach to building web applications. While the core functionality remains consistent, a closer look reveals subtle yet important differences.
The most apparent change lies in the updated code-red dependency, moving from version 0.1.3 in 3.29.3 to 0.1.4 in 3.29.4. While seemingly small, this could include bug fixes or performance enhancements within the code transformation process that code-red facilitates. The unpacked size of the distribution has also increased slightly, suggesting minor additions or modifications to the core codebase though the number of files remains the same. Svelte developers should note a later release date, with 3.29.4 deployed a few hours after 3.29.3.
For developers already using Svelte, upgrading to 3.29.4 is likely a low-risk operation. The consistently maintained devDependencies suggest stability and a continued commitment to a robust development environment. Developers should always consult the Svelte changelog or release notes for a comprehensive list of changes and potential breaking changes. Svelte offers a component-based approach encouraging efficient front-end development, simplifying complex applications. If you value performance and a reactive programming model, Svelte is worth investigating.
All the vulnerabilities related to the version 3.29.4 of the package
Svelte vulnerable to XSS when using objects during server-side rendering
The package svelte before 3.49.0 is 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.
Svelte has a potential mXSS vulnerability due to improper HTML escaping
A potential XSS vulnerability exists in Svelte for versions prior to 4.2.19.
Svelte improperly escapes HTML on server-side rendering. It converts strings according to the following rules:
" -> "& -> &< -> <& -> &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.
A vulnerable page (+page.svelte):
<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.
XSS, when using an attribute within a noscript tag