CVE-2026-56811 in phoenix
Summary
by MITRE • 07/07/2026
Allocation of Resources Without Limits or Throttling vulnerability in phoenixframework phoenix (Phoenix.Socket module) allows an unauthenticated attacker to cause a denial of service against any endpoint that mounts a Phoenix socket with a reachable channel transport (WebSocket or LongPoll).
This vulnerability is associated with program files lib/phoenix/socket.ex and program routine 'Elixir.Phoenix.Socket':handle_in/4.
Phoenix transports do not limit the number of channels that a single transport process may join. Every phx_join message a client sends over one connection starts a persistent channel process, and the socket process accepts an unbounded number of them. A single unauthenticated client can therefore open one WebSocket or LongPoll connection and stream a large number of phx_join messages, spawning hundreds of thousands of channel processes over that one connection and eventually reaching the BEAM maximum process limit. Once the process table is exhausted the virtual machine can no longer start new processes, denying service to legitimate traffic across the whole node. Because the amplification happens inside a single connection, network-layer connection caps and rate limiting do not mitigate it.
The fix adds a :max_channels_per_transport option (default 100) that bounds the number of channels a single transport process can join, forcing abusive clients to open many connections instead, where external load balancers and reverse proxies can throttle them.
This issue affects phoenix: from 0.11.0 before 1.5.15, 1.6.17, 1.7.24, and 1.8.9.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/07/2026
The Allocation of Resources Without Limits or Throttling vulnerability in the phoenixframework phoenix framework represents a critical denial of service weakness that specifically targets the Phoenix.Socket module and its channel transport mechanisms. This vulnerability operates at the core of how Phoenix handles real-time communication through WebSocket and LongPoll transports, creating an environment where resource exhaustion can occur without proper bounds on channel creation. The flaw exists within the program files lib/phoenix/socket.ex and particularly in the Elixir.Phoenix.Socket.handle_in/4 routine, making it a fundamental component of the framework's socket handling architecture.
The technical implementation of this vulnerability exploits the absence of channel limits within Phoenix transports, allowing any unauthenticated client to establish a single connection and continuously send phx_join messages that spawn persistent channel processes. Each join message initiates a new process that remains active until explicitly terminated, creating an unbounded resource allocation scenario where a single malicious connection can generate hundreds of thousands of channel processes. This process proliferation directly targets the BEAM virtual machine's process table limitations, which serve as the fundamental constraint on concurrent process execution within Elixir applications. The vulnerability specifically affects transport processes that handle WebSocket and LongPoll connections, creating a pathway for attackers to exhaust system resources through methodical process creation rather than network-level resource exhaustion.
The operational impact of this vulnerability manifests as complete service denial across the entire Phoenix application node when the BEAM maximum process limit is reached. Once the process table becomes exhausted, the virtual machine cannot create new processes, effectively halting all legitimate traffic and service functionality within that node. This creates a cascading failure effect where even normally functioning connections become unable to establish new channels or process messages, fundamentally breaking the application's real-time communication capabilities. The amplification factor occurs entirely within a single connection, meaning that network-level protections such as connection caps and rate limiting provide no defense against this attack vector because the malicious activity is contained within the established transport rather than occurring at the network boundary.
The mitigation strategy implemented in the patched versions introduces a configurable :max_channels_per_transport option with a default limit of 100 channels per transport process, fundamentally changing the attack surface by forcing abusive clients to establish multiple connections instead of exhausting resources through a single connection. This approach aligns with established security principles from CWE-770 which addresses allocation of resources without limits or throttling, and reflects techniques described in ATT&CK tactic TA0043 (Resource Exhaustion) that emphasize the importance of implementing resource bounds to prevent system-level denial of service conditions. The solution transforms a single-point attack vector into a multi-connection requirement that can be effectively managed by external infrastructure components such as load balancers, reverse proxies, and connection management systems that are designed to handle rate limiting and connection pooling scenarios.
This vulnerability demonstrates the critical importance of implementing resource bounds in concurrent programming environments, particularly within BEAM-based systems where process limits directly impact application availability. The fix addresses the root cause by establishing explicit upper bounds on channel creation while maintaining backward compatibility for legitimate use cases through configurable parameters. The affected versions span multiple major releases including phoenix 0.11.0 through 1.5.14, 1.6.0 through 1.6.16, 1.7.0 through 1.7.23, and 1.8.0 through 1.8.8, indicating that the vulnerability existed across a significant portion of the framework's history and required comprehensive patching across multiple version lines to ensure complete protection against this resource exhaustion attack pattern.