SvelteKit EUVD-2026-107011

Exploitation requires the target SvelteKit application to use enhanced form actions (use:enhance) on a route that accepts action paths beginning with a double slash (//), which the browser then treats as a protocol-relative URL to an attacker domain. The attack is limited by the need for active victim interaction (UI:A) to trigger the form action, and by the fact that only non-redirect form results are affected - it does not grant access to the vulnerable server itself (no C/I/A impact on the application), producing only off-site navigation of the victim's browser. Applications not using use:enhance, or not exposing routes that accept // action paths, are not affected.

This is a genuinely low-priority issue, and the signals are consistent rather than conflicting. The vendor's CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:A) scores only 2.1, reflecting that while the flaw is network-reachable and needs no privileges, it requires both active user interaction (UI:A) and a present attack requirement (AT:P) - namely a route that accepts action paths beginning with a double slash and uses enhanced form actions. The vulnerable system itself has no confidentiality, integrity, or availability impact (VC:N/VI:N/VA:N); the only impact is low integrity/confidentiality on a subsequent system (SC:L/SI:L), i.e. the victim's browser being navigated off-site. This is the classic low-severity profile of CWE-601 open redirect. No EPSS score, CISA KEV listing, or SSVC decision data was provided, and no public exploit is referenced, so there is no evidence of exploitation pressure. The realistic risk is that this becomes a building block in phishing/credential-harvesting campaigns rather than a standalone compromise - meaningful to fix, but not an emergency.

An attacker crafts a link to a legitimate SvelteKit application whose enhanced form action path begins with // (e.g. //evil.example), which the browser interprets as a protocol-relative URL. When a victim submits or is induced to trigger that form action, the non-redirect form result navigates their browser to the attacker-controlled domain, where a convincing phishing page can harvest credentials while appearing to originate from the trusted site. No public exploit code is referenced, and successful abuse depends on victim interaction with the manipulated form.