CVE-2026-32689: Phoenix Framework DoS Vulnerability

CVE-2026-32689 Overview

CVE-2026-32689 is a denial-of-service vulnerability in the Phoenix web framework for Elixir. The flaw resides in the long-poll transport's NDJSON body handling within Elixir.Phoenix.Transports.LongPoll.publish/4. An attacker sending a POST body composed entirely of newline bytes triggers unbounded list allocation, exhausting BEAM virtual machine memory and schedulers. The required session token is freely obtainable via an unauthenticated GET request with a matching Origin header, making the attack effectively unauthenticated. The issue affects Phoenix versions 1.7.0 through 1.7.21 and version 1.8.6, and is classified under [CWE-770] Allocation of Resources Without Limits or Throttling.

Critical Impact
A single 8 MB request can produce roughly 8.4 million empty list elements, crashing the Phoenix node and terminating all active sessions.

Affected Products

Phoenix Framework versions 1.7.0 through 1.7.21
Phoenix Framework version 1.8.6
Elixir applications using Phoenix.Transports.LongPoll with NDJSON content type

Discovery Timeline

2026-05-05 - CVE-2026-32689 published to NVD
2026-05-05 - Last updated in NVD database

Technical Details for CVE-2026-32689

Vulnerability Analysis

The vulnerability resides in Elixir.Phoenix.Transports.LongPoll.publish/4. When the transport receives a POST request with Content-Type: application/x-ndjson, the request body is split on newline characters using String.split/2 without a segment limit. Each newline byte in the input creates a new list element containing an empty binary, producing 1:1 amplification between input bytes and list size.

A 1 MB body of newline bytes generates approximately one million list elements. An 8 MB body produces approximately 8.4 million elements. The resulting list is then traversed by Enum.map, materializing a second list of equal size. This double allocation exhausts BEAM heap memory and starves schedulers, crashing the node and terminating every active long-poll session.

Root Cause

The root cause is missing input bounding on NDJSON body decoding. String.split/2 accepts a parts: option to cap segment count, but the original code omitted it. Combined with the absence of a server-side maximum batch size, the parser permits an attacker-controlled body to dictate allocation size linearly.

Attack Vector

The attack requires only network access to a Phoenix endpoint exposing the long-poll transport. An attacker first issues an unauthenticated GET to obtain a session token, supplying a matching Origin header. The attacker then sends a POST containing megabytes of \n bytes with Content-Type: application/x-ndjson. No authentication, user interaction, or privileges are needed.

javascript

// Patch: assets/js/phoenix/constants.js — introduces MAX_LONGPOLL_BATCH_SIZE
 export const global = globalSelf || phxWindow || globalThis
 export const DEFAULT_VSN = "2.0.0"
 export const SOCKET_STATES = {connecting: 0, open: 1, closing: 2, closed: 3}
+export const MAX_LONGPOLL_BATCH_SIZE = 100;
 export const DEFAULT_TIMEOUT = 10000
 export const WS_CLOSE_NORMAL = 1000
 export const CHANNEL_STATES = {

Source: Phoenix commit 1a67c61

javascript

// Patch: assets/js/phoenix/longpoll.js — imports the new batch limit constant
 import {
   SOCKET_STATES,
   TRANSPORTS,
-  AUTH_TOKEN_PREFIX
+  AUTH_TOKEN_PREFIX,
+  MAX_LONGPOLL_BATCH_SIZE
 } from "./constants"

 import Ajax from "./ajax"

Source: Phoenix commit 1a67c61

Detection Methods for CVE-2026-32689

Indicators of Compromise

POST requests to long-poll endpoints with Content-Type: application/x-ndjson and unusually large bodies relative to expected message volume.
Request bodies with extremely high newline-to-content ratios, particularly bodies composed primarily of \n bytes.
BEAM virtual machine crashes, scheduler stalls, or out of memory errors in Phoenix application logs coinciding with traffic to /socket/longpoll style routes.
Sudden mass disconnection of channel and LiveView sessions following a single client interaction.

Detection Strategies

Inspect web application firewall (WAF) and reverse proxy logs for NDJSON POSTs exceeding a sane upper bound, for example 1 MB.
Correlate Erlang VM telemetry — memory, run_queue, and process counts — with inbound long-poll traffic to identify allocation spikes.
Alert on repeated GETs that harvest session tokens from the same source address followed quickly by oversized NDJSON POSTs.

Monitoring Recommendations

Enable Phoenix Telemetry events for the long-poll transport and ship them to a centralized log platform for analysis.
Track 5xx response rates and BEAM node restarts per service instance and alert on deviations.
Monitor request body size distributions per route and flag outliers targeting long-poll endpoints.

How to Mitigate CVE-2026-32689

Immediate Actions Required

Upgrade Phoenix to a fixed release: 1.7.22 or later for the 1.7.x branch, or a release after 1.8.6 for the 1.8.x branch.
If upgrading is not immediately possible, disable the long-poll transport in endpoint.ex and rely solely on WebSocket transport.
Enforce a request body size cap at the reverse proxy or Plug.Parsers level for routes handling NDJSON.

Patch Information

The fix introduces a MAX_LONGPOLL_BATCH_SIZE constant (set to 100) on the client and bounds NDJSON segment processing on the server. Apply the official patches referenced in the GitHub Security Advisory GHSA-628h-q48j-jr6q and the upstream commits 1a67c61 and 912ea18. Additional context is published in the CNA advisory and OSV report.

Workarounds

Configure the reverse proxy (NGINX, HAProxy, or similar) to reject POST bodies above a few hundred kilobytes on long-poll routes.
Reject requests with Content-Type: application/x-ndjson at the edge if the application does not need NDJSON ingestion.
Restrict allowed Origin headers on the long-poll endpoint to limit unauthenticated token harvesting.

bash

# Example NGINX limit for the Phoenix long-poll endpoint
location /live/longpoll {
    client_max_body_size 256k;
    proxy_pass http://phoenix_upstream;
}