CVE-2026-56811: Phoenix Framework Socket DOS Vulnerability

CVE-2026-56811 Overview

CVE-2026-56811 is a denial of service vulnerability in the Phoenix web framework for Elixir, specifically in the Phoenix.Socket module. The flaw resides in lib/phoenix/socket.ex and the Elixir.Phoenix.Socket:handle_in/4 routine. Phoenix transports do not limit the number of channels a single transport process can join, allowing an unauthenticated attacker to send unbounded phx_join messages over one WebSocket or LongPoll connection. Each message spawns a persistent channel process, eventually exhausting the BEAM virtual machine process table and denying service to legitimate traffic across the entire node. The vulnerability is classified as Allocation of Resources Without Limits or Throttling [CWE-770].

Critical Impact
A single unauthenticated client can spawn hundreds of thousands of channel processes over one connection, exhausting the BEAM process table and taking down an entire Phoenix node.

Affected Products

Phoenix framework versions from 0.11.0 before 1.5.15
Phoenix framework versions from 1.6.0-rc.0 before 1.6.17 and from 1.7.0-rc.0 before 1.7.24
Phoenix framework versions from 1.8.0-rc.0 before 1.8.9

Discovery Timeline

2026-07-07 - CVE-2026-56811 published to NVD
2026-07-09 - Last updated in NVD database

Technical Details for CVE-2026-56811

Vulnerability Analysis

The Phoenix framework provides real-time channel functionality through WebSocket and LongPoll transports. Clients join channels by sending phx_join messages over an established transport connection. Each successful join spawns a persistent Elixir/OTP channel process supervised under the socket process.

The vulnerability stems from missing enforcement on how many channels a single transport process may join. The handle_in/4 function in lib/phoenix/socket.ex accepts an unbounded stream of phx_join messages on one connection. An attacker exploits this asymmetry by opening a single connection and streaming join requests until the BEAM virtual machine reaches its maximum process limit.

Once the process table is exhausted, the node can no longer spawn processes for legitimate users, HTTP handlers, or supervisors. The impact extends beyond channel functionality to the whole Erlang node.

Root Cause

The root cause is the absence of a per-transport channel cap in Phoenix.Socket. Network-layer connection limits and reverse proxy rate limiting do not mitigate the issue because the resource amplification occurs entirely within one authenticated transport connection.

Attack Vector

An unauthenticated remote attacker establishes a single WebSocket or LongPoll connection to any endpoint mounting a Phoenix socket with a reachable channel transport. The attacker then sends a high-volume stream of phx_join messages, each triggering channel process creation. The attack requires no privileges, no user interaction, and low complexity.

text

// Patch excerpt from lib/phoenix/socket.ex
       This option controls how many supervisors will be spawned
       to handle channels. Defaults to the number of cores.
 
+    * `:max_channels_per_transport` - the maximum number of channels that may be
+      joined per transport process. Defaults to `100`.
+
   ## Garbage collection
 
   It's possible to force garbage collection in the transport process after

Source: Phoenix commit 16e295d2

Detection Methods for CVE-2026-56811

Indicators of Compromise

A single client connection generating an abnormally high count of phx_join events in Phoenix telemetry or application logs.
Rapid growth of the BEAM process count, visible via :erlang.system_info(:process_count), approaching :process_limit.
Node-wide errors such as system_limit when spawning processes, or Supervisor restart storms tied to Phoenix.Channel.Server.
Elevated memory consumption and scheduler utilization correlated with sustained WebSocket or LongPoll traffic from a small number of source IPs.

Detection Strategies

Instrument the [:phoenix, :channel_joined] telemetry event and alert when per-transport join counts exceed a safe threshold.
Monitor BEAM VM metrics with tools such as :observer, :recon, or AppSignal for sudden spikes in process count.
Correlate reverse proxy access logs for long-lived WebSocket connections with disproportionate upstream message volume.

Monitoring Recommendations

Emit metrics on active channel count per transport PID and export them to Prometheus, Datadog, or an equivalent platform.
Configure alerts when the ratio of channel processes to open sockets exceeds normal baselines for your application.
Log source IP and user agent for connections that trigger channel join rate anomalies to support incident response.

How to Mitigate CVE-2026-56811

Immediate Actions Required

Upgrade Phoenix to 1.5.15, 1.6.17, 1.7.24, or 1.8.9 depending on your current major version branch.
Audit socket configurations in endpoint.ex and confirm the new :max_channels_per_transport option is set to an appropriate value.
Review reverse proxy configurations to throttle new WebSocket and LongPoll connections per source IP.

Patch Information

The fix introduces a new :max_channels_per_transport option in Phoenix.Socket that bounds the number of channels a single transport process can join. The default value is 100. Abusive clients must now open many connections to spawn many channels, exposing them to external load balancer and reverse proxy throttling. Patch details are available in the Phoenix GitHub Security Advisory GHSA-6983-jfq8-485w and the CNA advisory from EEF.

Workarounds

If immediate patching is not possible, apply per-IP connection rate limits at the reverse proxy or load balancer (for example, NGINX limit_conn or a WAF policy).
Implement an application-level counter in a custom Phoenix.Socket implementation that rejects phx_join messages once a per-transport channel threshold is reached.
Reduce the BEAM +P process limit exposure by monitoring and restarting nodes when process counts approach configured maximums.

bash

# Example: pin Phoenix to a fixed version in mix.exs
{:phoenix, "~> 1.7.24"}

# Configure the new option in your endpoint socket definition
# lib/my_app_web/endpoint.ex
socket "/socket", MyAppWeb.UserSocket,
  websocket: [max_channels_per_transport: 100],
  longpoll: [max_channels_per_transport: 100]