Django Daphne EUVD-2026-34091

The Daphne process must be serving a WebSocket route (i.e., a Django Channels ASGI application with at least one ws:// or wss:// consumer) reachable by the attacker, and that path must not be fronted by a proxy that enforces its own WebSocket message- or frame-size cap. The handshake must succeed to the application's ws endpoint, but no authentication, no user interaction, and no non-default Daphne configuration are required - the vulnerable behavior is the shipped default in versions 4.2.0-4.2.1. Limiting factors: HTTP-only Daphne deployments (no Channels/WebSocket consumers) are not exposed, and reverse proxies or WAFs that bound WebSocket payload size will block exploitation before Daphne allocates memory.

Signals are consistent and point to a moderate-priority availability bug rather than a critical incident. CVSS 7.5 with AV:N/AC:L/PR:N/UI:N matches the description - any internet-reachable Daphne WebSocket endpoint is exploitable without credentials or user interaction - and C:N/I:N/A:H correctly reflects pure DoS impact. SSVC reinforces this: Exploitation 'none' (no observed in-the-wild use), Automatable 'yes' (a trivial script can flood oversized frames), Technical Impact 'partial' (service degradation, not code execution or data loss). EPSS at 0.07% (22nd percentile) and absence from CISA KEV indicate no active exploitation. Notable caveat: the CVSS vector assumes the WebSocket endpoint is reachable; deployments that terminate WebSockets behind a reverse proxy enforcing message-size limits (e.g., nginx, Cloudflare) materially reduce real-world exposure, even though the underlying Daphne process remains vulnerable. Prioritize patching internet-facing Django Channels deployments; behind-LB internal services can follow normal patch cadence.

An attacker identifies an internet-reachable Django Channels application served by vulnerable Daphne and opens one or more WebSocket connections to a legitimate endpoint. Over each connection the attacker streams a single multi-gigabyte WebSocket message (or one continuous oversized frame), forcing the Daphne worker to buffer the unbounded payload in memory until the process is OOM-killed or the host swaps and becomes unresponsive. No authentication, user interaction, or specialized tooling is required, and the attack is trivially scriptable, though no public exploit identified at time of analysis.