Description
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.
Published: 2026-07-07
Score: 6.3 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Phoenix JavaScript presence client incorrectly verifies the existence of a presence entry by performing a simple truthiness test rather than an own‑property check. An attacker can supply a presence key that matches a member of JavaScript’s Object.prototype (for example __proto__, constructor, toString, hasOwnProperty). When such a key is processed, the client accesses properties on the prototype object, triggering a TypeError that aborts the presence synchronization handler. This crash causes the local sync state to never update and the onSync() callback never fires, resulting in a persistent client‑side denial of service for every user viewing that presence channel. The flaw does not modify the prototype or provide code execution; it only produces a continuous UI failure for the affected topic.

Affected Systems

The issue is present in the Phoenix framework’s JavaScript presence client shipped with Phoenix. Versions affected are all releases from 1.2.0‑rc.0 up to, but not including, 1.5.15; 1.6.0‑rc.0 up to, but not including, 1.6.17; 1.7.0‑rc.0 up to, but not including, 1.7.24; and 1.8.0‑rc.0 up to, but not including, 1.8.9. Applications that allow users to provide arbitrary presence identifiers such as usernames or session IDs without validation are vulnerable.

Risk and Exploitability

An attacker with ordinary channel access can supply a malicious presence key. The resulting TypeError propagates out of the sync handler but is not caught by higher‑level code, leaving the client in a broken state until the offending user disconnects. The CVSS score of 6.3 indicates moderate severity. The EPSS score of <1% implies a low likelihood of exploitation in the wild, and the vulnerability is not listed in CISA’s KEV catalog. Nonetheless, because the exploit requires only normal user privileges and can continuously disrupt the user interface of affected channels, the risk remains material for exposed or public channels.

Generated by OpenCVE AI on July 26, 2026 at 19:21 UTC.

Remediation

Vendor Workaround

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.

OpenCVE Recommended Actions

  • Update Phoenix to a version newer than the fixed releases (i.e., any release beyond 1.8.9).
  • If an upgrade is not immediately possible, reject or sanitize presence keys that collide with Object.prototype members (such as __proto__, constructor, prototype, toString, hasOwnProperty) before calling Phoenix.Presence.track, or enforce a fixed namespace prefix so that no key can equal a prototype member name.
  • If the application continues to rely on user‑supplied presence keys, modify the key generation logic so that keys are derived from server‑controlled, validated values rather than raw client input.

Generated by OpenCVE AI on July 26, 2026 at 19:21 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 07 Jul 2026 17:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'poc', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Tue, 07 Jul 2026 16:45:00 +0000

Type Values Removed Values Added
Description 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 are 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 before 1.5.15, from 1.6.0 before 1.6.17, from 1.7.0 before 1.7.24, and from 1.8.0 before 1.8.9. 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.

Tue, 07 Jul 2026 16:00:00 +0000

Type Values Removed Values Added
Description 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 are 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 before 1.5.15, from 1.6.0 before 1.6.17, from 1.7.0 before 1.7.24, and from 1.8.0 before 1.8.9.
Title Phoenix JavaScript presence client crashes on presence keys colliding with Object.prototype members in Presence.syncState/syncDiff
First Time appeared Phoenixframework
Phoenixframework phoenix
Weaknesses CWE-754
CPEs cpe:2.3:a:phoenixframework:phoenix:*:*:*:*:*:*:*:*
Vendors & Products Phoenixframework
Phoenixframework phoenix
References
Metrics cvssV4_0

{'score': 6.3, 'vector': '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'}

Subscriptions

Phoenixframework Phoenix
cve-icon MITRE

Status: PUBLISHED

Assigner: EEF

Published:

Updated: 2026-07-07T16:11:22.228Z

Reserved: 2026-06-23T12:29:02.507Z

Link: CVE-2026-56812

cve-icon Vulnrichment

Updated: 2026-07-07T16:10:49.072Z

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-07-26T19:30:03Z

Weaknesses
  • CWE-754

    Improper Check for Unusual or Exceptional Conditions