# CVE-2026-56812: Phoenix: Presence keys colliding with `Object.prototype` members break existence checks

> An attacker can crash the Phoenix JavaScript presence client for all users by using keys that collide with Object.prototype members, causing persistent denial of service.

- **Severity:** Medium 6.3 (`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`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 7 Jul 2026
- **Updated:** 24 Sep 2026
- **Also known as:** EEF-CVE-2026-56812, GHSA-63mc-hw7g-86rr

## What is CVE-2026-56812?

CVE-2026-56812 is a medium-severity denial of service vulnerability in phoenixframework phoenix, published on 7 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official 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; 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.

Weakness: CWE-754 (Improper Check for Unusual or Exceptional Conditions)

## Which versions are affected by CVE-2026-56812?

18 open source packages ship an affected version, including phoenix. It affects 1 product.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `phoenix` | Hex | From 1.2.0-rc.0 | 1.5.15, 1.6.17, 1.7.24, 1.8.9 |
| `phoenix` | Hex | From 1.2.0-rc.0 | 1.5.15 |
| `phoenix` | Hex | From 1.2.0-rc.0 | 1.5.15 |
| `phoenix` | Hex | From 1.6.0-rc.0 | 1.6.17 |
| `phoenix` | Hex | From 1.6.0-rc.0 | 1.6.17 |
| `phoenix` | Hex | From 1.7.0-rc.0 | 1.7.24 |
| `phoenix` | Hex | From 1.7.0-rc.0 | 1.7.24 |
| `phoenix` | Hex | From 1.8.0-rc.0 | 1.8.9 |
| `phoenix` | Hex | From 1.8.0-rc.0 | 1.8.9 |
| `phoenix` | npm | From 1.2.0-rc.0 | 1.5.15, 1.6.17, 1.7.24, 1.8.9 |
| `phoenix` | npm | From 1.2.0-rc.0 | 1.5.15 |
| `phoenix` | npm | From 1.2.0-rc.0 | 1.5.15 |
| `phoenix` | npm | From 1.6.0-rc.0 | 1.6.17 |
| `phoenix` | npm | From 1.6.0-rc.0 | 1.6.17 |
| `phoenix` | npm | From 1.7.0-rc.0 | 1.7.24 |
| `phoenix` | npm | From 1.7.0-rc.0 | 1.7.24 |
| `phoenix` | npm | From 1.8.0-rc.0 | 1.8.9 |
| `phoenix` | npm | From 1.8.0-rc.0 | 1.8.9 |

Products: Phoenixframework Phoenix.

## How do I fix CVE-2026-56812?

Upgrade phoenix to a fixed version for your release line: 1.5.15, 1.6.17, 1.7.24 or 1.8.9.

## Is CVE-2026-56812 being exploited?

It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-56812 exists.

## Other vulnerabilities in phoenixframework phoenix

- [CVE-2026-56811](https://insights.sbomify.com/CVE-2026-56811/): Phoenix transports do not limit channel joins per connection, enabling process-exhaustion denial of service (high 8.7)
- [CVE-2022-42975](https://insights.sbomify.com/CVE-2022-42975/): Phoenix before 1.6.14 mishandles check_origin wildcarding (high 7.5)
- [CVE-2017-1000163](https://insights.sbomify.com/CVE-2017-1000163/): Phoenix Arbitrary URL Redirect (medium 6.1)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-56812 and fix it if it is affected.

What it is: CVE-2026-56812 is a medium-severity denial of service vulnerability in phoenixframework phoenix, published on 7 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-56812 exists.

Affected packages and fixed versions:
- phoenix (Hex): affected from 1.2.0-rc.0; fixed in 1.5.15, 1.6.17, 1.7.24, 1.8.9
- phoenix (Hex): affected from 1.2.0-rc.0; fixed in 1.5.15
- phoenix (Hex): affected from 1.2.0-rc.0; fixed in 1.5.15
- phoenix (Hex): affected from 1.6.0-rc.0; fixed in 1.6.17
- phoenix (Hex): affected from 1.6.0-rc.0; fixed in 1.6.17
- phoenix (Hex): affected from 1.7.0-rc.0; fixed in 1.7.24
- phoenix (Hex): affected from 1.7.0-rc.0; fixed in 1.7.24
- phoenix (Hex): affected from 1.8.0-rc.0; fixed in 1.8.9
- phoenix (Hex): affected from 1.8.0-rc.0; fixed in 1.8.9
- phoenix (npm): affected from 1.2.0-rc.0; fixed in 1.5.15, 1.6.17, 1.7.24, 1.8.9
- phoenix (npm): affected from 1.2.0-rc.0; fixed in 1.5.15
- phoenix (npm): affected from 1.2.0-rc.0; fixed in 1.5.15

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-56812/ (Markdown: https://insights.sbomify.com/CVE-2026-56812/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-56812
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-56812
- OSV: https://osv.dev/vulnerability/CVE-2026-56812

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-56812/
Summaries are generated and may contain mistakes; the official description above is the record.
