Phoenix Framework CVE-2026-32689

Exploitation requires the Phoenix application to expose the long-poll transport endpoint (typically /socket/longpoll) to the attacker's network. Applications using WebSocket-only transport or those with long-poll disabled in endpoint.ex socket configuration are not vulnerable. The vulnerable code path is triggered specifically by POST requests with Content-Type: application/x-ndjson; other content types bypass the vulnerable String.split call. A session token is required in the request but is obtained via an unauthenticated GET request to the same endpoint with a matching Origin header, effectively making the attack unauthenticated. No user interaction is required (UI:N in CVSS). The attack succeeds against default Phoenix configurations that include long-poll as a fallback transport, which is standard in Phoenix 1.7.x and 1.8.x scaffolded projects. Memory-constrained deployments (containers with <512 MB heap) crash faster than large instances, but all unpatched versions are exploitable regardless of hardware resources given sufficient payload size (8 MB body crashes typical production configurations). Network access to the endpoint is the sole prerequisite; authentication, privileges, and special client capabilities are not required.

Real-world risk is high for publicly exposed Phoenix applications using long-poll transport. CVSS:4.0 8.7 (AV:N/AC:L/PR:N/UI:N/VA:H) accurately reflects the unauthenticated network vector and high availability impact. Attack complexity is low: the vulnerability requires only a single HTTP POST with an 8 MB body of newlines. EPSS data not provided, but the attack primitive (send large request, crash service) is trivial to automate. No CISA KEV listing or public POC identified, suggesting exploitation has not yet been observed in the wild or widely weaponized. However, the advisory (GHSA-628h-q48j-jr6q) and patches are public since early 2025, so exploitation is technically feasible for any attacker monitoring Phoenix security advisories. The free availability of session tokens via unauthenticated GET (with matching Origin header) removes authentication as a barrier. The primary risk limiting factor is deployment configuration: only applications exposing the long-poll transport endpoint (typically /socket/longpoll) to untrusted networks are at risk. Modern deployments favor WebSocket over long-poll, reducing the attack surface, but legacy or fallback configurations remain vulnerable. Mitigation is straightforward (upgrade to patched version), but unpatched instances face immediate DoS risk. The server-side fix is incomplete (batching limit enforced client-side only), so defense-in-depth via reverse proxy rate limiting is advisable even after patching.

An attacker crafts an HTTP POST to https://target.example/socket/longpoll with Content-Type: application/x-ndjson and an 8 MB body consisting entirely of newline bytes (0x0A). First, they obtain a session token by sending a GET request to the same URL with an Origin header matching the target domain, which returns a token without authentication. Using this token, they submit the malicious POST. The Phoenix server's publish/4 function calls String.split on the body, materializing approximately 8.4 million empty binaries in a list. Enum.map then walks this list, doubling the allocation. The BEAM VM exhausts memory within seconds, crashing the node and disconnecting all active WebSocket and long-poll sessions. The attack is repeatable and can be automated. If multiple application nodes exist behind a load balancer, the attacker can sequentially crash each node or send concurrent requests to crash the entire cluster.