CVE-2026-58228 in phoenix_live_view
Summary
by MITRE • 07/13/2026
Cross-site scripting vulnerability in phoenixframework phoenix_live_view allows an attacker to bypass URL scheme validation and execute JavaScript in a victim's browser session.
The Phoenix.LiveView.Utils.valid_destination!/2 and Phoenix.LiveView.Utils.valid_live_navigation_destination!/2 functions in lib/phoenix_live_view/utils.ex rely on an internal uri_scheme/1 helper that only detects a scheme when the input's first byte is an ASCII letter. Inputs beginning with an ASCII control character or space fall through to a nil-returning clause, causing the URL to be treated as a safe relative path.
Standard browsers implement the WHATWG URL parser, which strips leading C0 control and space characters before parsing. As a result, an input such as " javascript:alert(1)" is passed unchanged into <.link href={...}> and, when clicked, is parsed by the browser as a javascript: URL that executes attacker-controlled script in the victim's session.
Applications that render user-supplied URLs (for example profile links, redirect targets, or external references) via <.link href={...}> are affected.
This issue affects phoenix_live_view: from 1.2.2 before 1.2.7.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/13/2026
This cross-site scripting vulnerability resides within the phoenix_live_view framework's URL validation mechanisms, specifically targeting the Phoenix.LiveView.Utils.valid_destination/2 functions located in lib/phoenix_live_view/utils.ex. The flaw stems from an inadequate uri_scheme/1 helper function that performs scheme detection by examining only the first byte of input data, requiring it to be an ASCII letter. When URLs begin with ASCII control characters or spaces, the validation logic fails to recognize the scheme and instead falls through to a nil-returning clause, effectively treating such inputs as safe relative paths rather than potentially malicious absolute URLs.
The vulnerability exploits a fundamental mismatch between the framework's validation approach and browser URL parsing behavior, creating a security gap that attackers can leverage for code execution. Standard web browsers implement the WHATWG URL parser specification which automatically strips leading C0 control characters and spaces before processing URLs, meaning that an input like " javascript:alert(1)" gets normalized by the browser to "javascript:alert(1)" during parsing. This normalization process causes the framework's validation to incorrectly classify the URL as a safe relative path while the browser interprets it as a javascript: protocol URL capable of executing arbitrary JavaScript code within the victim's session context.
The impact extends to applications that render user-supplied URLs through the <.link href={...}> component, making profile links, redirect targets, and external reference points potential attack vectors. This represents a classic client-side validation bypass where server-side security checks fail to account for browser-level URL normalization behaviors, creating a scenario where malicious inputs can successfully traverse validation boundaries. The vulnerability affects all phoenix_live_view versions from 1.2.2 through 1.2.6, leaving applications in this range susceptible to XSS attacks that could compromise user sessions and potentially lead to further exploitation.
From a cybersecurity perspective, this vulnerability aligns with CWE-79 (Cross-site Scripting) and represents an implementation weakness in the URL validation subsystem that enables attackers to manipulate the application's security model. The ATT&CK framework categorizes this under T1531 (Run-time Application Protocol Execution) as it leverages legitimate browser protocol handling to execute malicious JavaScript code through crafted URL inputs. The attack surface is particularly concerning because it requires no privileged access or complex exploitation techniques, simply requiring an attacker to inject a specially formatted URL into user-controllable input fields that get rendered within the application's link components.
The security implications extend beyond simple script execution to potential session hijacking and data exfiltration attacks, as attackers can leverage the executed JavaScript to steal cookies, manipulate application state, or redirect users to malicious sites. Organizations should prioritize immediate patching of affected versions, implementing proper input validation that accounts for browser-level normalization behaviors rather than relying solely on server-side scheme detection. Additionally, defensive measures including content security policies and comprehensive input sanitization should be implemented as additional safeguards against similar vulnerabilities in other components that may not properly account for browser URL parsing discrepancies.