GHSA-63MC-HW7G-86RR
Vulnerability from github – Published: 2026-09-03 20:30 – Updated: 2026-09-03 20:30Summary
The Phoenix JavaScript presence client (assets/js/phoenix/presence.js) tests whether a presence already exists using a bare truthiness check (state[key]) rather than an own-property check. Because applications commonly track presences under a client-supplied username or id, the presence key can be attacker-controlled. A user who joins a channel and picks a key that names an Object.prototype member (__proto__, constructor, toString, hasOwnProperty, and similar) makes the lookup return the inherited Object.prototype object instead of undefined, which is truthy. The code then reads .metas.map(...) off it and throws an uncaught TypeError, breaking presence sync for every viewer of that channel topic. Any authenticated channel participant can trigger it.
Details
The victim is any browser subscribed to a presence channel. When it receives the server's presence_state message, it invokes Presence.syncState, which iterates the incoming presences and checks whether each one already exists locally via let currentPresence = state[key]. state is a plain object inheriting from Object.prototype. For an ordinary key like alice, state["alice"] is undefined (falsy) and the safe path runs. For the key __proto__ (or constructor, toString, etc.), state["__proto__"] does not resolve to a tracked presence but to JavaScript's built-in Object.prototype, which is truthy. The if(currentPresence) guard passes, and the code evaluates currentPresence.metas.map(m => m.phx_ref). Since Object.prototype.metas is undefined, calling .map on it throws a TypeError.
Phoenix wraps no try/catch around channel binding callbacks, so the TypeError propagates out of the message handler: this.state is never updated and onSync() never fires. The malicious key is tracked server-side, so it is re-pushed on every presence update and keeps re-throwing, leaving presence permanently broken until the attacker leaves. Presence.syncDiff uses the same unsafe state[key] existence-check pattern, so presence diffs fail identically.
Two scoping points matter. The impact is per channel topic, not global: presence state is per-topic on the server and per-Presence-instance in the browser, so only viewers of the topic carrying the malicious key are affected. The bug is a read-time confusion of the prototype object, not prototype pollution: the crash occurs on the state["__proto__"] read in syncState, before any state[key] = ... write is reached, so Object.prototype is never mutated and nothing leaks across channels. The fix builds the state and accumulator objects with Object.create(null) (or a Map) and gates existence checks with Object.prototype.hasOwnProperty.call(obj, key).
If an application does not pass a client-controlled key to Presence.track, it is not affected.
PoC
- Connect to an application that uses
Phoenix.Presenceand tracks presences under a client-chosen key (e.g. a username). - Join a presence channel choosing the key
__proto__(orconstructor,toString,hasOwnProperty). - The server tracks the presence and pushes
presence_state/presence_diffto every subscriber of that topic. - Each viewer's
Presence.syncState(orsyncDiff) readsstate["__proto__"], gets the truthyObject.prototype, and throws an uncaughtTypeError. - Presence sync stays broken for all viewers of the topic until the attacker leaves the channel.
Impact
An attacker with ordinary channel access can cause a persistent, stored client-side denial of service against every browser viewing a presence channel topic, freezing presence updates for all of them until the attacker disconnects. Any application driving the Phoenix JavaScript presence client with user-influenced presence keys is affected.
{
"affected": [
{
"package": {
"ecosystem": "Hex",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0-rc.0"
},
{
"fixed": "1.5.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Hex",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.6.0-rc.0"
},
{
"fixed": "1.6.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Hex",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0-rc.0"
},
{
"fixed": "1.7.24"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Hex",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.8.0-rc.0"
},
{
"fixed": "1.8.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0-rc.0"
},
{
"fixed": "1.5.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.6.0-rc.0"
},
{
"fixed": "1.6.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0-rc.0"
},
{
"fixed": "1.7.24"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "phoenix"
},
"ranges": [
{
"events": [
{
"introduced": "1.8.0-rc.0"
},
{
"fixed": "1.8.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56812"
],
"database_specific": {
"cwe_ids": [
"CWE-754"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T20:30:33Z",
"nvd_published_at": "2026-07-07T16:16:40Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe Phoenix JavaScript presence client (`assets/js/phoenix/presence.js`) tests whether a presence already exists using a bare truthiness check (`state[key]`) rather than an own-property check. Because applications commonly track presences under a client-supplied username or id, the presence key can be attacker-controlled. A user who joins a channel and picks a key that names an `Object.prototype` member (`__proto__`, `constructor`, `toString`, `hasOwnProperty`, and similar) makes the lookup return the inherited `Object.prototype` object instead of `undefined`, which is truthy. The code then reads `.metas.map(...)` off it and throws an uncaught `TypeError`, breaking presence sync for every viewer of that channel topic. Any authenticated channel participant can trigger it.\n\n### Details\n\nThe victim is any browser subscribed to a presence channel. When it receives the server\u0027s `presence_state` message, it invokes `Presence.syncState`, which iterates the incoming presences and checks whether each one already exists locally via `let currentPresence = state[key]`. `state` is a plain object inheriting from `Object.prototype`. For an ordinary key like `alice`, `state[\"alice\"]` is `undefined` (falsy) and the safe path runs. For the key `__proto__` (or `constructor`, `toString`, etc.), `state[\"__proto__\"]` does not resolve to a tracked presence but to JavaScript\u0027s built-in `Object.prototype`, which is truthy. The `if(currentPresence)` guard passes, and the code evaluates `currentPresence.metas.map(m =\u003e m.phx_ref)`. Since `Object.prototype.metas` is `undefined`, calling `.map` on it throws a `TypeError`.\n\nPhoenix wraps no try/catch around channel binding callbacks, so the `TypeError` propagates out of the message handler: `this.state` is never updated and `onSync()` never fires. The malicious key is tracked server-side, so it is re-pushed on every presence update and keeps re-throwing, leaving presence permanently broken until the attacker leaves. `Presence.syncDiff` uses the same unsafe `state[key]` existence-check pattern, so presence diffs fail identically.\n\nTwo scoping points matter. The impact is per channel topic, not global: presence state is per-topic on the server and per-`Presence`-instance in the browser, so only viewers of the topic carrying the malicious key are affected. The bug is a read-time confusion of the prototype object, not prototype pollution: the crash occurs on the `state[\"__proto__\"]` read in `syncState`, before any `state[key] = ...` write is reached, so `Object.prototype` is never mutated and nothing leaks across channels. The fix builds the state and accumulator objects with `Object.create(null)` (or a `Map`) and gates existence checks with `Object.prototype.hasOwnProperty.call(obj, key)`.\n\nIf an application does not pass a client-controlled key to `Presence.track`, it is **not** affected.\n\n### PoC\n\n1. Connect to an application that uses `Phoenix.Presence` and tracks presences under a client-chosen key (e.g. a username).\n2. Join a presence channel choosing the key `__proto__` (or `constructor`, `toString`, `hasOwnProperty`).\n3. The server tracks the presence and pushes `presence_state` / `presence_diff` to every subscriber of that topic.\n4. Each viewer\u0027s `Presence.syncState` (or `syncDiff`) reads `state[\"__proto__\"]`, gets the truthy `Object.prototype`, and throws an uncaught `TypeError`.\n5. Presence sync stays broken for all viewers of the topic until the attacker leaves the channel.\n\n### Impact\n\nAn attacker with ordinary channel access can cause a persistent, stored client-side denial of service against every browser viewing a presence channel topic, freezing presence updates for all of them until the attacker disconnects. Any application driving the Phoenix JavaScript presence client with user-influenced presence keys is affected.",
"id": "GHSA-63mc-hw7g-86rr",
"modified": "2026-09-03T20:30:33Z",
"published": "2026-09-03T20:30:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/phoenixframework/phoenix/security/advisories/GHSA-63mc-hw7g-86rr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56812"
},
{
"type": "WEB",
"url": "https://github.com/phoenixframework/phoenix/commit/7f7b971c1ea0994e3fbd1c11ddb05e780bd38ad8"
},
{
"type": "WEB",
"url": "https://github.com/phoenixframework/phoenix/commit/89a1c4be161e436241e12b2378a719904b9bd96f"
},
{
"type": "WEB",
"url": "https://github.com/phoenixframework/phoenix/commit/b90b22521465ece00eb5a19d5aa2b9465b209c85"
},
{
"type": "WEB",
"url": "https://github.com/phoenixframework/phoenix/commit/beffc4da1e787e572121f68902c63daf4fe7d9c2"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-56812.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/phoenixframework/phoenix"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-56812"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "Phoenix: Presence keys colliding with `Object.prototype` members break existence checks"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.