Phoenix Framework EUVD-2026-42050

The attacker must be able to join a Phoenix Channel topic that uses Phoenix Presence tracking, and the application must allow the attacker to control the string used as their presence key (typically a username, display name, or client-supplied session identifier). Both Presence.syncState and Presence.syncDiff use the same vulnerable pattern, so either code path can be triggered. Exploitation is prevented if the application assigns server-generated presence keys (e.g., numeric database IDs or UUIDs) rather than accepting free-form client strings, since an attacker cannot then supply a prototype-colliding key. Impact is bounded to the single channel topic the attacker joins and lasts only as long as the attacker remains connected. No server-side code is affected and no mutation of Object.prototype occurs - the attacker cannot leverage this to escalate beyond client-side availability disruption.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N, score 6.3) accurately captures the attack profile: network-accessible, low complexity, no elevated privileges, but gated by the Attack Requirement that the attacker must be able to join the targeted channel (AT:P). Impact is purely a low-severity client-side availability loss with no confidentiality, integrity, or server-side consequences. The vulnerability is not listed in CISA KEV and no public proof-of-concept exploit was provided in the input; EPSS data is absent. Despite the moderate score, the persistence mechanism significantly amplifies real-world impact: because the malicious key is tracked server-side, it is re-broadcast on every presence update, meaning the TypeError re-throws continuously rather than once. In applications where presence is a core UX signal - real-time collaboration, live event attendee lists, chat rooms - this persistent breakage could be highly disruptive to all legitimate users of an affected topic. Risk is bounded, however, by the requirement for channel access: if applications gate channel joins behind authentication or assign server-generated presence keys (e.g., numeric user IDs) rather than accepting free-form client-supplied strings, exploitation is prevented.

An attacker connects to a Phoenix Channel whose topic uses Phoenix Presence tracking and sends a join payload specifying 'toString' (or any other Object.prototype member) as their presence key - an operation indistinguishable from a normal join. The Phoenix server records this presence and broadcasts it to all subscribers; every affected viewer's browser-side Presence.syncState or Presence.syncDiff then throws an uncaught TypeError when processing the update, freezing their presence display. The attacker remains connected, causing the server to re-broadcast the malicious key on every subsequent presence event, ensuring presence sync stays permanently broken for all viewers of that topic.