CVE-2026-56812

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

HIGH
7.5
CVSS Score
Published: July 7, 2026 at 03:22 PM UTC
Updated: October 25, 2026 at 08:10 PM UTC
1 product affected across 1 vendorPhoenix

Using phoenix by phoenixframework?

Get instant alerts when new vulnerabilities affect phoenix - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.5
Exploit prediction
EPSS 0.8%
SSVC
PoC

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

1.2.0 ≤ v < 1.5.151.6.0 ≤ v < 1.6.171.7.0 ≤ v < 1.7.241.8.0 ≤ v < 1.8.91.2.0-rc.01.6.0-rc.01.7.0-rc.01.8.0-rc.02270aaf21bd02c6a6a1022820564efb605a97655
Affected range stops below 1.5.15, so it looks safe — our inference, not a vendor statement
Affected range stops below 1.6.17, so it looks safe — our inference, not a vendor statement
Affected range stops below 1.7.24, so it looks safe — our inference, not a vendor statement
Affected range stops below 1.8.9, so it looks safe — our inference, not a vendor statement

SSVC — Action Prioritization

SSVCPoCNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

Attack Vector
NETWORK
Complexity
LOW
Privileges
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-754

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card