Contents of hydratable promises were not properly stringified, potentially leading to an XSS exploit. You are vulnerable if all of the following is true: you are using hydratable (an experimental feature at the time of this report) you are passing attacker-controlled input such that a synchronous value is hydrated, then a promise value, e.g. hydratable('someKey', () => [synchronousValue, promiseValue])
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.
Svelte was vulnerable to DOM clobbering of its internal framework state on elements, potentially leading to XSS attacks. You are vulnerable if all of the following is true: you are using attribute spreading on a form element you are using attribute spreading or allow a dynamic value for the name attribute on an input or button element within that form both of these are simultaneously user-controllable <form {…spread1}> <input {…spread2}> …
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. …
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.
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.
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.
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.
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.
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.
A server-side rendered <textarea> with two-way bound value does not have its value correctly escaped in the rendered HTML.
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.
A potential XSS vulnerability exists in Svelte for versions prior to 4.2.19.
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.