GHSA-6983-jfq8-485w: High severity erlang/phoenix vulnerability
Summary
Phoenix transports do not limit the number of channels in a given connection, making it easy to spawn hundreds of thousands of processes over a single connection, and, eventually reaching the max processes VM limit. The solution is to limit the number of channels per transport, so an attacker needs to start new HTTP/WebSocket connections, allowing third-party services to apply rate limits and intervene more easily.
Impact
An unauthenticated remote attacker can cause a denial of service against any Phoenix app that exposes LongPoll/WebSocket transports.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
erlang/phoenixto a version that resolves this vulnerability.Fixed in 1.8.9 - Upgrade
Upgrade
erlang/phoenixto a version that resolves this vulnerability.Fixed in 1.7.24 - Upgrade
Upgrade
erlang/phoenixto a version that resolves this vulnerability.Fixed in 1.6.17 - Upgrade
Upgrade
erlang/phoenixto a version that resolves this vulnerability.Fixed in 1.5.15
Event History
Frequently Asked Questions
Which deployments are exposed to this denial-of-service risk?
Any Phoenix application that exposes LongPoll or WebSocket transports is affected. The attacker does not need authentication.
What does an attacker need to do to trigger the issue?
An attacker can use a single connection to create a very large number of channels, spawning hundreds of thousands of processes. This can eventually exhaust the Erlang VM maximum process limit and deny service.
What changes reduce the risk if the fix cannot be deployed immediately?
The provided information identifies the underlying mitigation as limiting the number of channels per transport. Requiring new HTTP or WebSocket connections for additional channels allows third-party rate-limiting services to intervene more easily.