SEC.co
Emergency
MEDIUM 6.1

CVE-2026-42599: Svelte Event Handler Injection via Spread Attributes

Svelte, a popular web framework, contains a vulnerability where untrusted data rendered as HTML attributes can include malicious event handlers. If your application uses Svelte's spread syntax to render attributes from user input or external sources, attackers could inject code that runs when users interact with those elements. The risk is reduced if Svelte's hydration process completes before the injected event fires, but this shouldn't be relied upon as a defense. Version 5.55.7 and later address this issue.

Source data · NVD / CISA · public domain

CVSS
3.1 · 6.1 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Weaknesses (CWE)
CWE-79
Affected products
1 configuration(s)
Published / Modified
2026-06-09 / 2026-06-17

NVD description (verbatim)

Svelte is a performance oriented web framework. Prior to version 5.55.7, 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. This issue has been patched in version 5.55.7.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-42599 is a cross-site scripting (XSS) vulnerability in Svelte prior to version 5.55.7. When spread syntax (e.g., {...obj}) is used to bind attributes from untrusted sources to DOM elements, event handler properties within that data object are included verbatim in the rendered HTML rather than being processed as framework-controlled listeners. This allows event handler injection (onclick, onload, onerror, etc.) in the HTML layer. The vulnerability requires user interaction and JavaScript to be enabled. Svelte's hydration mechanism may mitigate exploitation if it attaches proper event listeners before user interaction, but this is not a reliable barrier and should not be considered a workaround.

Business impact

Applications using Svelte to render user-supplied or third-party data as element attributes face XSS risk. Attackers could steal session tokens, deface content, redirect users, or perform actions on behalf of victims. The blast radius depends on data source proximity—internal data sources pose lower risk than public-facing forms or API integrations. Teams should audit spread usage patterns in their codebase and prioritize patching in customer-facing applications or those handling sensitive user workflows.

Affected systems

Svelte versions prior to 5.55.7 are affected. The vulnerability requires the specific use of spread syntax to apply attributes from untrusted data. Applications using static attributes or safely filtered data are not affected. Verify your Svelte version in package.json or package-lock.json.

Exploitability

The vulnerability is practically exploitable and requires minimal complexity. An attacker needs to control or influence data that is spread as element attributes—a common pattern in modern web applications. The attack requires user interaction (clicking an element, hovering, etc.) and JavaScript execution, which are standard on the web. No authentication or special privileges are needed. The CVSS score of 6.1 (MEDIUM) reflects these factors: network-accessible attack surface, low complexity, no authentication required, but user interaction and limited impact scope.

Remediation

Upgrade Svelte to version 5.55.7 or later. Review your application code for patterns where user-controlled or external data is spread directly as element attributes (e.g., <input {...userData} />). For any such patterns, validate or sanitize the data before spreading, or use controlled bindings instead of spread syntax. If regenerating lock files after upgrade, test in a staging environment to confirm no regressions.

Patch guidance

Update Svelte via npm/yarn: run 'npm update svelte' or 'yarn upgrade svelte' to pull version 5.55.7 or later. Review the Svelte release notes for version 5.55.7 to confirm any breaking changes (unlikely for a patch bump, but verify against the vendor advisory). Redeploy your application after testing. If you have pinned a Svelte version in package.json, edit it to '^5.55.7' or your preferred semantic versioning constraint, then run install again.

Detection guidance

Search your codebase for spread syntax applied to element attributes, particularly near form inputs or data rendering (grep for patterns like '{...', '<input {', '<div {'). Examine whether the spread object could originate from user input, API responses, or other untrusted sources. Monitor application logs for unusual onclick/onerror payloads in HTTP requests or CSP violations. Run a static analysis tool (ESLint, SonarQube) configured for XSS patterns. Test suspect components in a controlled environment by injecting mock malicious attributes and observing whether event handlers fire.

Why prioritize this

While the CVSS score is MEDIUM, Svelte is widely used in production applications, and XSS vulnerabilities are impactful despite lower severity ratings. The attack surface is broad—any application spreading user data as attributes is at risk. The fix is a straightforward patch with minimal friction, making this a high-priority candidate for immediate remediation in customer-facing deployments.

Risk score, explained

CVSS 3.1 score of 6.1 (MEDIUM) reflects: AV:N (network-accessible), AC:L (low attack complexity), PR:N (no privileges needed), UI:R (requires user interaction), S:C (impacts scope beyond the vulnerable component), C:L (low confidentiality impact—session theft or minor data exposure), I:L (low integrity impact—limited ability to alter content), A:N (no availability impact). The user interaction requirement and single-click nature of exploitation prevent a higher score; however, XSS in widely-deployed frameworks warrants prompt patching regardless of CVSS.

Frequently asked questions

Do I need to patch if I never spread untrusted data?

Likely not, but audit your codebase to be certain. If all spread objects come from internal, validated sources that cannot include event handler properties, your risk is minimal. However, given the straightforward upgrade path, patching remains prudent as a preventative measure and to avoid future refactoring mistakes.

Does this vulnerability require a network request or can it be triggered offline?

No network is required to trigger the vulnerability itself. Once malicious HTML is rendered in the browser (whether from an initial page load or a dynamic update), an attacker just needs the user to interact with the element. However, injecting the malicious data into the application typically requires either a man-in-the-middle attack, a compromised API, or compromised user input—which do require network attack surface.

Will my existing CSP policy protect me?

A strict CSP (Content Security Policy) that blocks inline event handlers may mitigate some forms of this attack, but CSP is not a reliable defense and should not replace patching. Svelte's event handler injection occurs at the HTML layer, and CSP policies vary in how they handle attribute-based handlers. Patch Svelte and enforce CSP as a defense-in-depth measure, not a substitute.

Why does Svelte's hydration not fully prevent this?

Hydration attaches framework-aware event listeners after the initial HTML is parsed and rendered. However, if a user interacts with an element before hydration completes (or in an edge case where hydration skips the element), the injected inline event handler in the HTML attribute will fire, bypassing Svelte's protections. This timing race condition is the core issue Svelte 5.55.7 fixes by preventing event handlers from being injected into HTML in the first place.

This analysis is based on the CVE record and vendor advisory dated June 2026. CVSS scores and vulnerability status may change as new information emerges. Always consult the official Svelte release notes and security advisories before deploying patches. This document does not constitute legal or professional security advice; your organization should conduct its own risk assessment and testing. Patch versions, remediation steps, and affected product lists should be verified against vendor sources before implementation. Source: NVD (public-domain), retrieved 2026-07-15. Analysis generated by SEC.co (claude-haiku-4-5).

Affected vendors

svelte

Weaknesses (CWE)

CWE-79

Related vulnerabilities