Svelte version 3.4.4 introduces subtle but potentially impactful changes compared to its predecessor, 3.4.3. Both versions champion Svelte's core philosophy of creating cybernetically enhanced web applications, boasting lean dependencies and a MIT license for open-source flexibility. Examining the devDependencies reveals the primary shifts. Most of the tooling remains consistent, ensuring a familiar development experience for those upgrading. However, eslint and eslint-plugin-html and eslint-plugin-import are removed from version 3.4.4. This could hint at internal adjustments to linting strategies or potentially a reliance on alternative code quality checks. This change might introduce minor workflow impacts with developers needing to adjust linting configurations. This can be somehow important for developers that use this tool in their workflow.
Furthermore, the dist object shows a change in package size. Version 3.4.4 has a fileCount of 180, unlike version 3.4.3 with 27 files. The unpackedSize of 3.4.4 is 1152091 comparing to 1037422. This suggests internal restructuring, potentially involving more granular modules or optimized packaging, while the second one implies a small increase in overall library size. Developers should consider this size difference, especially when optimizing for minimal bundle sizes. The dates of release are very close to each other so the changes will not be very substantial.
All the vulnerabilities related to the version 3.4.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