Vulnerabilities

Phoenix's WebSocket and LongPoll transports place no limit on the number of channels a single connection can join, allowing an unauthenticated remote client to cause the application to spawn hundreds of thousands of processes and hit the Erlang VM's maximum process limit. The flaw is triggered simply by connecting to an exposed LongPoll or WebSocket endpoint on a Phoenix app and joining a very large number of channels over one connection. The result is denial of service (high availability impact only, per the CVSS 4.0 score of 8.7), with no confidentiality or integrity impact. Any Phoenix application exposing these transports is affected; the source data does not specify affected or fixed version ranges. Exploitation has not been observed: there is no public proof-of-concept, the issue is not in CISA KEV, and EPSS estimates about a 0.8% probability of exploitation within 30 days.

Do: Upgrade to a patched Phoenix release that caps the number of channels per transport as soon as one is available (check the Phoenix security advisory for the fixed version, which is not stated in this data). As interim mitigation, cap or rate-limit concurrent WebSocket/LongPoll connections per client IP at your reverse proxy or load balancer and monitor Erlang VM process counts for unusual growth; applications that do not need LongPoll/WebSocket transports can disable them.

tag.ex in Phoenix Phoenix.HTML (aka phoenix_html) before 3.0.4 allows XSS in HEEx class attributes.

socket/transport.ex in Phoenix before 1.6.14 mishandles check_origin wildcarding. NOTE: LiveView applications are unaffected by default because of the presence of a LiveView CSRF token.

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 unvalidated URL redirection, which may result in phishing or social engineering attacks.