CVE-2026-56811Patch(phoenixframework / phoenix)

LOWCVSS 7.5 · HIGH

Signal is active with 1 mentions in latest observed window

Immediate actions

  • Patch phoenixframework phoenix systems immediately

Recommended action window: Monitor and triage in normal cycle

NVD description

Allocation of Resources Without Limits or Throttling vulnerability in phoenixframework phoenix (Phoenix.Socket module) allows an unauthenticated attacker to cause a denial of service against any endpoint that mounts a Phoenix socket with a reachable channel transport (WebSocket or LongPoll). This vulnerability is associated with program files lib/phoenix/socket.ex and program routine 'Elixir.Phoenix.Socket':handle_in/4. Phoenix transports do not limit the number of channels that a single transport process may join. Every phx_join message a client sends over one connection starts a persistent channel process, and the socket process accepts an unbounded number of them. A single unauthenticated client can therefore open one WebSocket or LongPoll connection and stream a large number of phx_join messages, spawning hundreds of thousands of channel processes over that one connection and eventually reaching the BEAM maximum process limit. Once the process table is exhausted the virtual machine can no longer start new processes, denying service to legitimate traffic across the whole node. Because the amplification happens inside a single connection, network-layer connection caps and rate limiting do not mitigate it. The fix adds a :max_channels_per_transport option (default 100) that bounds the number of channels a single transport process can join, forcing abusive clients to open many connections instead, where external load balancers and reverse proxies can throttle them. This issue affects phoenix: from 0.11.0 before 1.5.15, from 1.6.0-rc.0 before 1.6.17, from 1.7.0-rc.0 before 1.7.24, and from 1.8.0-rc.0 before 1.8.9.

0.5/ 10 priority

Sources & remediation

Weakness type (CWE)
CWE-770

Priority

LOW

Exploitation

NONE

PoC

NONE

Patch

AVAILABLE

Momentum

STABLE

Are you affected?

If you run products in this scope, you should treat this CVE as relevant to your environment.

  • phoenix

Threat summary

  • Patch or workaround signal is available
  • 2 mentions across 2 observed days
  • Momentum state: stable

What's happening

  • Patch or workaround mentioned in 1 signal
  • Technical details provided in 2 signals
  • Disclosure: 1 classified signal
  • Peaked 1d ago at 1 mentions (2026-07-07); latest day: 1
  • 2 total mentions across 2 days

Affected systems

Products
phoenix

Deep dive

Activity timeline2 mentions / 2d
00111Mentions · 2026-07-07: 1Mentions · 2026-09-04: 1Patch / Workaround · 2026-07-07: 1Technical Details · 2026-07-07: 1Technical Details · 2026-09-04: 107-0709-04
Signal classification2 categories
Patch
150.0%
Disclosure
150.0%
Referenced assets1 URL
Classification over time
DateTotalLabels
2026-07-071
Patch1
2026-09-041
Disclosure1
Full discourse2 posts
  • DailyCVE@dailycve
    Disclosure

    🔴 Phoenix, Allocation of Resources Without Limits or Throttling, #CVE-2026-56811 (High) -DC-Sep2026-2168 https://dailycve.com/phoenix-allocation-of-resources-without-limits-or-throttling-cve-2026-56811-high-dc-sep2026-2168/

    Post summary

    A new CVE (CVE-2026-56811) is announced, describing a high‑severity resource allocation flaw in Phoenix; no exploitation evidence, PoC, or patch details are provided.

    0000039
    233 followersView on X
  • Upwind Security MDR@UpwindMDR
    Patch

    🚨High - Phoenix Framework Unbounded Channel Joins DoS (CVE-2026-56811) Phoenix's Phoenix.Socket transports don't cap how many channels a single transport process can join. Every phx_join a client sends over one connection spawns a persistent channel process, with no limit. A single unauthenticated client can open one WebSocket or LongPoll connection and stream a flood of phx_join messages, spawning hundreds of thousands of channel processes until the BEAM process table is exhausted. Once that limit is hit, the VM can't start new processes and the whole node stops serving legitimate traffic. Because the amplification is inside one connection, network-level connection caps and rate limiting don't help. The fix adds :max_channels_per_transport (default 100). 👉Upgrade Phoenix to 1.5.15, 1.6.17, 1.7.24, or 1.8.9.

    Post summary

    The notice details a DoS flaw in Phoenix’s unbounded channel joins and stresses applying the provided patch (upgrade to specified versions) to prevent exhaustion of BEAM processes.

    0000082
    243 followersView on X
CPE platform detail1 entries

1 of 1 entries

PartVendorProductVersionTarget SWTarget HW
Appphoenixframeworkphoenix---

Explore more