Skip to content
Threat Feed
low advisory

Phoenix Transport Channel Exhaustion Denial of Service

The Phoenix web framework lacks limits on channels per transport, allowing an unauthenticated attacker to cause a DoS by exhausting Erlang VM process limits via CVE-2026-56811.

CVE search metadata

CVE search record: CVE-2026-56811. Severity: high. CVSS: 7.5. EPSS: 0.76%. KEV: no. Product: Phoenix (>= 0.11.0, < 1.5.15), Phoenix (>= 1.6.0-rc.0, < 1.6.17), Phoenix (>= 1.7.0-rc.0, < 1.7.24), Phoenix (>= 1.8.0-rc.0, < 1.8.9). Brief: Phoenix Transport Channel Exhaustion Denial of Service. Brief link: https://feed.craftedsignal.io/briefs/2026-09-phoenix-dos/

The Phoenix web framework is vulnerable to a denial of service (DoS) condition due to an unbounded number of concurrent channel joins allowed over a single transport connection (LongPoll or WebSocket). By initiating a single connection, an unauthenticated remote attacker can programmatically trigger the creation of hundreds of thousands of Erlang processes. This behavior rapidly consumes system resources, eventually exceeding the Erlang VM's maximum process limit and resulting in a service crash. The issue, tracked as CVE-2026-56811, affects various versions across the 1.5, 1.6, 1.7, and 1.8 release branches. Defenders should note that because the exhaustion occurs within the application transport layer, standard infrastructure rate limiting may be ineffective unless applied at the connection level rather than the channel level.

Impact

Successful exploitation results in a complete denial of service for any Phoenix-based application exposing LongPoll or WebSocket transports. As this does not require authentication, any internet-facing Phoenix instance is susceptible to resource exhaustion, potentially impacting critical production systems and causing significant downtime until the service is manually restarted or mitigated via patching.

Recommendation

  1. Patch Phoenix immediately to the corrected versions: v1.5.15, v1.6.17, v1.7.24, or v1.8.9.
  2. Implement aggressive rate limiting on connection establishment at the load balancer or reverse proxy level to mitigate the impact of rapid connection cycles.
  3. Monitor Erlang VM metrics, specifically process counts and memory usage, for anomalous spikes that do not correlate with legitimate user traffic volume.

Immediate actions

Upgrade Phoenix to 1.5.15 or later

IT Operations 24h

Mitigations

Apply connection-based rate limiting at the edge/load balancer

immediate IT Operations

CVE-2026-56811