EUVD-2026-42049
GHSA-6983-jfq8-485w
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Remote, unauthenticated, low-complexity single-connection abuse of a default channel transport with no interaction; pure availability impact, so C:N/I:N/A:H.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
Lifecycle Timeline
1DescriptionCVE.org
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.
AnalysisAI
Denial of service in the Phoenix Framework (Elixir) affects any endpoint mounting a Phoenix.Socket with a reachable WebSocket or LongPoll channel transport, in versions from 0.11.0 up to the fixed 1.5.15, 1.6.17, 1.7.24, and 1.8.9. Because transports place no cap on channels joined per connection, one unauthenticated client can stream unlimited phx_join messages down a single connection to spawn hundreds of thousands of channel processes and exhaust the BEAM process table, taking the whole node offline. Rated CVSS 4.0 8.7 (availability-only impact); no public exploit identified at time of analysis, though the mechanics are described in detail in the vendor advisory.
Technical ContextAI
Phoenix is the dominant web framework for the Elixir language, running on the BEAM (Erlang virtual machine), where each channel and each socket connection is a lightweight process. Real-time features are delivered through Phoenix.Socket transports (WebSocket and LongPoll), and clients multiplex logical 'channels' over a single transport by sending phx_join messages, each handled by Elixir.Phoenix.Socket:handle_in/4 in lib/phoenix/socket.ex. The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the socket process accepted an unbounded number of channel joins per connection, and every join starts a persistent channel process. Because the BEAM enforces a global maximum process count per node, unbounded per-connection channel spawning lets a single connection consume the node-wide process table rather than just its own connection's resources.
RemediationAI
Vendor-released patch: upgrade to the fixed release for your branch - 1.5.15, 1.6.17, 1.7.24, or 1.8.9 (or any later release) - per advisory GHSA-6983-jfq8-485w (https://github.com/phoenixframework/phoenix/security/advisories/GHSA-6983-jfq8-485w). The fix introduces a :max_channels_per_transport option that defaults to 100, bounding channels per transport process; review this default and tune it to your legitimate multiplexing needs, since applications that intentionally join many channels over one socket may need a higher value (raising it too far weakens the protection). Fix commits are c498ba8cf49f6accbbd0c643a5340b58db891218, d19ca0a8d9f82c130b7ed339b9f033433e2dea5e, a612100cd8a4279091abc1a2ef8fb98a6d01c0a1, and 16e295d2fccab185d1292322e2bee5d46c725c8a. If you cannot upgrade immediately, the effective compensating control is to bound BEAM resources and channel growth: raise the node's +P process limit ceiling and monitor process counts to fail loudly rather than silently exhausting, restrict or authenticate access to the socket endpoint so only trusted clients can send phx_join, or disable the WebSocket/LongPoll transport on endpoints that do not require real-time channels (trade-off: this breaks live features). Note that per-connection rate limiting at a load balancer will NOT help, since the amplification occurs within a single connection.
The Phoenix Framework versions 1.0.0 through 1.0.4, 1.1.0 through 1.1.6, 1.2.0, 1.2.2 and 1.3.0-rc.0 are vulnerable to u
In Phoenix SCT WinFlash 1.1.12.0 through 1.5.74.0, the included drivers could be used by a malicious Windows application
Unauthenticated remote denial-of-service in Phoenix Framework 1.7.0-1.7.21 and 1.8.0-1.8.5 allows attackers to crash Eli
socket/transport.ex in Phoenix before 1.6.14 mishandles check_origin wildcarding. Rated high severity (CVSS 7.5), this v
Phoenix Framework's Presence JavaScript client allows any user with ordinary channel access to permanently break presenc
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today