Phoenix JavaScript presence client crashes on presence keys colliding with Object.prototype members in Presence.syncState/syncDiff

## Summary Improper Check for Unusual or Exceptional Conditions vulnerability in phoenixframework phoenix (Presence JavaScript client) allows an attacker with ordinary channel access to cause a persistent client-side denial of service against every viewer of a presence channel topic. This vulnerability is associated with program files `assets/js/phoenix/presence.js` and program routines `Presence.syncState` and `Presence.syncDiff`. The Phoenix JavaScript presence client checks whether a presence already exists with a bare truthiness test (`state[key]`) instead of an own-property check. Presence keys can be attacker-controlled, because applications track presences under a username or id supplied by the client. A user who joins a channel choosing a key that is an `Object.prototype` member name (`__proto__`, `constructor`, `toString`, `hasOwnProperty`, and similar) makes that lookup return JavaScript's built-in `Object.prototype` instead of `undefined`. Because the prototype is truthy, the code treats it as an existing presence and reads `.metas.map(...)` off it, which throws an uncaught `TypeError`. The exception propagates out of the presence message handler, so the local state is never updated and `onSync()` never fires. Because the malicious key is tracked on the server, it is re-pushed on every presence update and keeps re-throwing, so presence sync stays broken for every viewer of that channel topic until the attacker leaves. Both `syncState` and `syncDiff` use the same unsafe existence-check pattern. The impact is limited to the affected topic and is a read-time confusion of the prototype object, not a mutation of `Object.prototype` (it is not prototype pollution). This issue affects phoenix: from 1.2.0-rc.0 before 1.5.15, from 1.6.0-rc.0 before 1.6.17, from 1.7.0-rc.0 before 1.7.24, and from 1.8.0-rc.0 before 1.8.9; phoenix: from 1.2.0-rc.0 before 1.5.15, from 1.6.0-rc.0 before 1.6.17, from 1.7.0-rc.0 before 1.7.24, and from 1.8.0-rc.0 before 1.8.9. ## Workarounds Reject or sanitize presence keys that collide with JavaScript `Object.prototype` member names (for example `__proto__`, `constructor`, `prototype`, `toString`, `hasOwnProperty`) before calling `Phoenix.Presence.track`, or namespace every presence key with a fixed prefix so that no key can equal a prototype member name. Alternatively, derive presence keys from server-controlled, validated values instead of raw user input. ## Configurations The application must use `Phoenix.Presence` (or otherwise drive the Phoenix JavaScript presence client) and track presences under keys that are influenced by untrusted client input, for example a username or id chosen by the connecting user. Applications that derive presence keys exclusively from server-controlled, validated values are not affected.

Source published

7 Jul 2026 15:22:46 UTC

Source modified

24 Sep 2026 21:30:06 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N