Steffen Deusch

**Name of the Vulnerable Software and Affected Versions** phoenix live view versions 0.5.0 through 1.0.18 phoenix live view versions 1.1.0-rc.0 through 1.1.32 phoenix live view versions 1.2.0-rc.0 through 1.2.8 **Description** An Open Redirect issue exists where an attacker can redirect a victim's browser to an arbitrary origin. This occurs because the `redirect/2` function uses `validate local url!/2` to ensure the target is a local path, but it fails to reject ASCII tab, LF, or CR characters. Since browsers strip these characters before parsing the URL, a value like `/<TAB>/example.com` bypasses validation and is interpreted as a scheme-relative URL. The `push patch/2` function is also affected in versions prior to 0.7.0. The issue is triggered when the application passes an externally influenced value as the `:to` parameter, such as a `return to` parameter during sign-in or a navigation target from a `handle event/3` payload. **Recommendations** Update phoenix live view to version 1.0.19 or later. Update phoenix live view to version 1.1.33 or later. Update phoenix live view to version 1.2.9 or later. Reject any untrusted value containing ASCII tab, LF, or CR before passing it as the `:to` parameter to `redirect/2` or `push patch/2` (for versions prior to 0.7.0). Map client-supplied navigation targets to a fixed set of known-good paths instead of forwarding the value directly.

**Name of the Vulnerable Software and Affected Versions** phoenix live view versions 1.2.2 through 1.2.6 **Description** A cross-site scripting issue exists in phoenix live view due to improper URL scheme validation. The functions `valid destination!/2` and `valid live navigation destination!/2` use an internal `uri scheme/1` helper that fails to detect schemes if the input begins with a space or an ASCII control character. Because standard browsers strip these leading characters before parsing, an attacker can provide a payload like " javascript:alert(1)" that bypasses validation and is treated as a safe relative path. When rendered via `<.link href={...}>`, the browser executes the script in the victim's session. This affects applications that render user-supplied URLs, such as redirect targets or profile links. **Recommendations** Update phoenix live view to version 1.2.7 or later.

**Name of the Vulnerable Software and Affected Versions** phoenix versions 0.11.0 through 1.5.14 phoenix versions 1.6.0-rc.0 through 1.6.16 phoenix versions 1.7.0-rc.0 through 1.7.23 phoenix versions 1.8.0-rc.0 through 1.8.8 **Description** An unauthenticated attacker can cause a denial of service against any endpoint mounting a Phoenix socket with a reachable channel transport, such as WebSocket or LongPoll. The issue resides in the `Elixir.Phoenix.Socket`:handle in/4 routine within the lib/phoenix/socket.ex file. Because Phoenix transports do not limit the number of channels a single transport process can join, a client can send an unbounded number of phx join messages over one connection. This spawns excessive channel processes, potentially exhausting the BEAM maximum process limit and preventing the virtual machine from starting new processes for legitimate traffic. This amplification occurs within a single connection, rendering network-layer connection caps and rate limiting ineffective. **Recommendations** Update phoenix to version 1.5.15 or later. Update phoenix to version 1.6.17 or later. Update phoenix to version 1.7.24 or later. Update phoenix to version 1.8.9 or later. Configure the `:max channels per transport` option to bound the number of channels a single transport process can join.

**Name of the Vulnerable Software and Affected Versions** phoenix versions 1.2.0-rc.0 through 1.5.14 phoenix versions 1.6.0-rc.0 through 1.6.16 phoenix versions 1.7.0-rc.0 through 1.7.23 phoenix versions 1.8.0-rc.0 through 1.8.8 **Description** The Presence JavaScript client in phoenix contains an improper check for unusual conditions that allows an attacker with ordinary channel access to cause a persistent client-side denial of service for all viewers of a presence channel topic. The issue resides in the `assets/js/phoenix/presence.js` file within the `Presence.syncState()` and `Presence.syncDiff()` routines. The client uses a bare truthiness test (`state[key]`) instead of an own-property check to verify if a presence exists. Since presence keys are attacker-controlled, a user can provide a key that matches an `Object.prototype` member name (such as ` proto `, `constructor`, `toString`, or `hasOwnProperty`). This causes the lookup to return the built-in `Object.prototype` instead of `undefined`, leading the code to attempt to read `.metas.map(...)` from the prototype, which throws an uncaught `TypeError`. This exception prevents the local state from updating and stops `onSync()` from firing. Because the server continues to push the malicious key, the synchronization remains broken for all viewers of the topic until the attacker leaves. This is a read-time confusion of the prototype object and not prototype pollution. **Recommendations** Update phoenix to version 1.5.15 or later. Update phoenix to version 1.6.17 or later. Update phoenix to version 1.7.24 or later. Update phoenix to version 1.8.9 or later.