CVE-2026-56812: Phoenix Framework Presence Denial of Service via Prototype Confusion

Technical summary

The vulnerability exists in phoenix/presence.js, specifically in the Presence.syncState and Presence.syncDiff functions. Both routines use a bare truthiness check (state[key]) to determine whether a presence record already exists, instead of employing an own-property check like hasOwnProperty(). When a client supplies an Object.prototype member name as a presence key—such as __proto__, constructor, toString, hasOwnProperty, valueOf, or similar—the lookup returns JavaScript's built-in Object.prototype rather than undefined. Because Object.prototype is truthy, the code treats it as an existing presence object and attempts to call .metas.map(...) on it, which throws an uncaught TypeError. This exception is never caught, preventing the local state from updating and onSync() from firing. Since the malicious key persists on the server and is re-broadcast on every presence update, it re-triggers the same error for every client, keeping presence sync broken. This is not prototype pollution (no mutation of Object.prototype occurs); it is a read-time confusion that exploits the prototype chain.

Business impact

Production applications using Phoenix presence for real-time features—such as collaborative tools, live dashboards, or multi-user sessions—become unusable for all channel viewers once exploited. The attack requires no authentication beyond channel join permissions, making it accessible to any user with legitimate access. For SaaS or multi-tenant platforms, a single malicious user can degrade service for an entire audience. The denial of service is complete and persistent, lasting until the attacker disconnects. This can damage user trust, interrupt critical workflows, and create support burden if the root cause is misdiagnosed as infrastructure failure.

Affected systems

Phoenix Framework versions 1.2.0-rc.0 through 1.5.14, 1.6.0-rc.0 through 1.6.16, 1.7.0-rc.0 through 1.7.23, and 1.8.0-rc.0 through 1.8.8 are vulnerable. Any application running these versions that exposes a Phoenix presence channel is at risk if it allows user-supplied data to influence presence keys. Applications that do not use presence channels are unaffected.

Exploitability

Exploitability is high. An attacker needs only ordinary channel access—no special privileges, no complex exploitation steps, no race conditions. The attack surface is broad: any application permitting user-controlled presence keys is vulnerable. Triggering the vulnerability requires only a single malicious presence join; no additional interaction or user behavior is needed. The attack is deterministic and immediately observable as a service outage. No patched client or special tools are required; a standard Phoenix client configured with a malicious key is sufficient.

Remediation

Upgrade to patched versions: 1.5.15 or later, 1.6.17 or later, 1.7.24 or later, or 1.8.9 or later. Applications should prioritize patching based on their current version branch. As an interim mitigation, restrict or validate presence key inputs on the server side to reject keys matching Object.prototype member names, though this is a defense-in-depth measure and not a substitute for patching.

Patch guidance

The Phoenix maintainers have released patched versions in all affected branches. Update your phoenix dependency to the earliest patched version in your current branch: versions 1.5.15, 1.6.17, 1.7.24, or 1.8.9 and later all contain the fix. Verify the patch by checking that presence.js includes an own-property check (such as Object.prototype.hasOwnProperty.call(state, key)) instead of a bare truthiness test. After patching, clear any cached client-side bundles and redeploy. Test presence functionality across your application, especially with edge-case usernames, before moving to production.

Detection guidance

Monitor for uncaught TypeErrors in browser consoles tied to presence operations, particularly 'Cannot read property metas of undefined' or similar prototype-related errors. Server-side, track presence key names; unusual keys matching Object.prototype methods (e.g., __proto__, constructor, toString) may indicate malicious joins. Log presence join attempts with suspicious keys and correlate them with client-side outages in the same channel. Presence sync breakage manifesting suddenly for all viewers of a topic is a strong indicator of this attack. Review application logs and analytics for unexpected drops in active presence counts.

Why prioritize this

This is a HIGH-severity vulnerability (CVSS 7.5) that is trivial to exploit and affects all Phoenix presence deployments without authentication barriers. The attack surface is broad—any user with channel access can exploit it—and the impact is immediate and disruptive. While not on the KEV list yet, the ease of exploitation and real-world impact to production systems make it a priority for any organization running affected Phoenix versions. The fix is straightforward and low-risk, supporting urgent patching.

Risk score, explained

CVSS 3.1 score of 7.5 reflects HIGH severity: no authentication required (PR:N), low complexity (AC:L), network-based attack (AV:N), no scope change (S:U), no confidentiality or integrity impact (C:N/I:N), but high availability impact (A:H). The vulnerability denies service to all viewers of a channel, satisfying high availability impact. The low barrier to exploitation and broad attack surface reinforce the need for rapid remediation.

Frequently asked questions