CVE-2026-56811: Phoenix Framework Unbounded Channel Allocation Denial of Service

Technical summary

Phoenix.Socket.handle_in/4 in the Phoenix.Socket module processes incoming phx_join messages without enforcing a per-transport channel limit. An unauthenticated client establishes one WebSocket or LongPoll transport connection and streams repeated phx_join messages, each spawning a new channel process. Because the Erlang/OTP BEAM runtime has a finite process table, an attacker can exhaust this limit—potentially reaching hundreds of thousands of channels on a single connection—causing the entire BEAM node to fail when attempting to allocate new processes for any purpose. The vulnerability exists because the socket process accepts an unbounded number of channel join requests from a single transport without throttling. The remediation adds a :max_channels_per_transport configuration option (default value 100) that enforces a hard cap per transport connection, shifting the attack surface from internal process exhaustion to one where attackers must establish multiple external connections that can be rate-limited by load balancers and reverse proxies.

Business impact

Applications using vulnerable Phoenix versions face a trivial denial-of-service attack vector. An attacker with network access can crash the application or degrade it to the point of unavailability without authentication. This affects the availability pillar of security: users cannot access the service, potentially impacting revenue, customer trust, and SLAs. The attack requires no specialized knowledge—only the ability to send WebSocket frames or HTTP long-poll requests. For organizations running multi-tenant or publicly accessible Phoenix applications, this is a critical operational risk.

Affected systems

Phoenix framework versions 0.11.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 built on these versions that exposes a Phoenix socket endpoint with WebSocket or LongPoll transport is at risk. Applications that do not use Phoenix.Socket (pure HTTP-only Phoenix apps) are not affected. The vulnerability is transport-agnostic: both WebSocket and LongPoll connections can be exploited in the same way.

Exploitability

Exploitation is trivial and requires no authentication. An attacker needs only network connectivity to the Phoenix socket endpoint and the ability to send repeated phx_join messages over a single transport connection. No special tools are required beyond a WebSocket client or HTTP client. The attack is reliable and deterministic—it will succeed against any vulnerable endpoint. There is no known public exploit code, but the attack is straightforward enough that attackers can implement it in hours. Network-based defenses (connection-rate limiting, IP blocking) are ineffective because the attack amplifies through a single connection; only per-connection channel limits or patching will stop it.

Remediation

Upgrade Phoenix to version 1.5.15 or later (for the 1.5.x series), 1.6.17 or later (for the 1.6.x series), 1.7.24 or later (for the 1.7.x series), or 1.8.9 or later (for the 1.8.x series). After upgrading, optionally configure the :max_channels_per_transport option in your socket configuration if you need to adjust the default limit of 100 channels per connection. No interim mitigations are available other than disabling socket endpoints or placing them behind additional authentication gates that require human interaction.

Patch guidance

Identify which versions of Phoenix your applications depend on by checking mix.lock or your mix.exs dependencies. Cross-reference your versions against the vulnerability ranges (0.11.0–1.5.14, 1.6.0-rc.0–1.6.16, 1.7.0-rc.0–1.7.23, 1.8.0-rc.0–1.8.8). If affected, update your mix.exs to specify the patched versions listed above. Run `mix deps.update phoenix` to pull the fixed version, then recompile and test thoroughly. Pay attention to any breaking changes in the release notes, though the :max_channels_per_transport option is backward compatible and defaults to 100. Consider adjusting this limit upward only if your application legitimately requires individual clients to join many channels simultaneously; most applications should use the default.

Detection guidance

Monitor your BEAM node's process count in real time using observer or :erlang.system_info(:process_count). A sudden spike in process count from a single source IP or connection indicates an active attack. Log phx_join messages and alert if a single transport connection accumulates an unusually high number of channel joins (e.g., >50 joins in a short window). If you cannot patch immediately, enable detailed logging in Phoenix.Socket and correlate spikes in process count with connection source IPs. Consider implementing a temporary reverse-proxy rule to block clients that open WebSocket connections and send >N join messages within a time window.

Why prioritize this

This vulnerability scores 7.5 (HIGH) on CVSS 3.1 because it is network-accessible, requires no authentication, and causes complete denial of service to the affected application. While it does not compromise confidentiality or integrity, the attack is trivial to execute and the impact is severe. Organizations should patch within 30 days, prioritizing internet-facing applications. Internal applications behind strict network access controls can be patched on a longer timeline, but should still be addressed promptly.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects: (1) Network vector (AV:N) – attack requires only network access, no proximity; (2) Low complexity (AC:L) – no special conditions or user interaction required; (3) No privileges required (PR:N) – unauthenticated attacker can trigger the vulnerability; (4) No user interaction (UI:N) – attack is automatic; (5) Unchanged scope (S:U) – impact is limited to the Phoenix application itself; (6) High availability impact (A:H) – the entire service becomes unavailable. The vector does not include confidentiality or integrity impact because the attack is purely denial of service.

Frequently asked questions