CyberSecBulletin
CVE-2026-56812NVD status: Modified

phoenix: Improper Check for Unusual or Exceptional Conditions

Published Updated By the CyberSecBulletin desk

CVE-2026-56812 is a high-severity improper check for unusual or exceptional conditions vulnerability in phoenix from Phoenixframework, with a CVSS 3.1 base score of 7.5 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists versions 1.5.15, 1.6.17, 1.7.24 as the first without the flaw, so updating phoenix to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.8% chance of exploitation within 30 days, higher than 57% of scored CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update phoenix to 1.5.15 or 1.6.17 or 1.7.24 or 1.8.9, whichever matches your release line, or a later version.
  2. Read the advisory on github.com for workarounds and exact fixed builds.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
Phoenixframeworkphoenix1.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; 1.8.0-rc.0 up to, but not including, 1.8.9; 2270aaf21bd02c6a6a1022820564efb605a97655 and later1.5.15, 1.6.17, 1.7.24, 1.8.9

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
NoneNo data is disclosed.
Integrity
NoneNothing can be modified.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Scored by NVD.

Scoring systemScoreSeverityScored by
CVSS 4.06.3MediumCNA
CVSS 3.17.5HighNVD

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.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Improper Check for Unusual or Exceptional Conditions

The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

How developers prevent this class of flaw

  • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
  • Check the results of all functions that return a value and verify that the value is expected.
  • If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).

More Improper Check for Unusual or Exceptional Conditions vulnerabilities (CWE-754)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: poc, automatable: no, technical impact: partial).
  3. Record last changed materially (score, affected products, status or references).

References

Other vulnerabilities in phoenix

All phoenix vulnerabilities

Recent Improper Check for Unusual or Exceptional Conditions vulnerabilities

Spotted an error? Tell us.