CVE-2026-56811: CWE-770 Allocation of Resources Without Limits or Throttling in phoenixframework phoenix
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, 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.
AI Analysis
Technical Summary
This vulnerability (CVE-2026-56811) in phoenixframework phoenix's Phoenix.Socket module (specifically in lib/phoenix/socket.ex and the handle_in/4 routine) allows an unauthenticated attacker to cause a denial of service by exploiting the lack of limits on the number of channels a single transport process may join. An attacker can open one WebSocket or LongPoll connection and send many phx_join messages, spawning hundreds of thousands of channel processes and exhausting the BEAM process table. This prevents the virtual machine from starting new processes, denying service to all legitimate traffic on the node. The amplification occurs within a single connection, so network-layer connection caps and rate limiting do not mitigate the attack. The framework introduced a :max_channels_per_transport option (default 100) to limit channels per transport process, forcing abusive clients to open multiple connections where external throttling can be applied. The vulnerability affects phoenix versions from 0.11.0 before 1.5.15, 1.6.0 before 1.6.17, 1.7.0 before 1.7.24, and 1.8.0 before 1.8.9. No explicit patch or official fix status is provided in the data.
Potential Impact
An unauthenticated attacker can cause a denial of service by exhausting the BEAM process table on a node running an affected Phoenix version. This prevents new processes from starting, effectively denying service to all legitimate users on that node. The attack bypasses typical network-layer rate limiting because the amplification happens within a single WebSocket or LongPoll connection. This can severely disrupt availability of applications using the Phoenix framework with vulnerable versions.
Mitigation Recommendations
The Phoenix framework introduced a :max_channels_per_transport option (defaulting to 100) to limit the number of channels a single transport process can join, mitigating the risk by forcing abusive clients to open multiple connections that can be throttled externally. However, the provided data does not confirm an official patch or remediation level. Users should upgrade to versions 1.5.15, 1.6.17, 1.7.24, or 1.8.9 or later where this option is available. Patch status is not yet confirmed — check the vendor advisory for current remediation guidance.
CVE-2026-56811: CWE-770 Allocation of Resources Without Limits or Throttling in phoenixframework phoenix
Description
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, 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.
CVSS v4.0
Score 8.7high
Affected software
pkg:hex/phoenixcpe:2.3:a:phoenixframework:phoenix:*:*:*:*:*:*:*:*Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
This vulnerability (CVE-2026-56811) in phoenixframework phoenix's Phoenix.Socket module (specifically in lib/phoenix/socket.ex and the handle_in/4 routine) allows an unauthenticated attacker to cause a denial of service by exploiting the lack of limits on the number of channels a single transport process may join. An attacker can open one WebSocket or LongPoll connection and send many phx_join messages, spawning hundreds of thousands of channel processes and exhausting the BEAM process table. This prevents the virtual machine from starting new processes, denying service to all legitimate traffic on the node. The amplification occurs within a single connection, so network-layer connection caps and rate limiting do not mitigate the attack. The framework introduced a :max_channels_per_transport option (default 100) to limit channels per transport process, forcing abusive clients to open multiple connections where external throttling can be applied. The vulnerability affects phoenix versions from 0.11.0 before 1.5.15, 1.6.0 before 1.6.17, 1.7.0 before 1.7.24, and 1.8.0 before 1.8.9. No explicit patch or official fix status is provided in the data.
Potential Impact
An unauthenticated attacker can cause a denial of service by exhausting the BEAM process table on a node running an affected Phoenix version. This prevents new processes from starting, effectively denying service to all legitimate users on that node. The attack bypasses typical network-layer rate limiting because the amplification happens within a single WebSocket or LongPoll connection. This can severely disrupt availability of applications using the Phoenix framework with vulnerable versions.
Mitigation Recommendations
The Phoenix framework introduced a :max_channels_per_transport option (defaulting to 100) to limit the number of channels a single transport process can join, mitigating the risk by forcing abusive clients to open multiple connections that can be throttled externally. However, the provided data does not confirm an official patch or remediation level. Users should upgrade to versions 1.5.15, 1.6.17, 1.7.24, or 1.8.9 or later where this option is available. Patch status is not yet confirmed — check the vendor advisory for current remediation guidance.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- EEF
- Date Reserved
- 2026-06-23T12:29:02.507Z
- Cvss Version
- 4.0
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a4d2240c9d9e3dbe3707e81
Added to database: 07/07/2026, 15:58:56 UTC
Last enriched: 07/07/2026, 16:13:19 UTC
Last updated: 07/07/2026, 16:44:04 UTC
Views: 4
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.