Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify exposed Channels WebSocket endpoint
-
DeliveryOpen ws/wss connection to consumer
-
ExploitStream oversized frame or message
-
ExecutionDaphne buffers payload unbounded via Autobahn
-
PersistWorker memory exhausted, process OOM-killed
-
ImpactService denial for legitimate users
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | 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. |
| Impact | 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. |
| Exploit ScenarioDerived | 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. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv3 – Jun 15, 2026
Denial of service in Django Daphne before 4.2.2 allows unauthenticated remote attackers to exhaust server memory by sending oversized WebSocket frames or messages. The flaw stems from Daphne failing to forward maxFramePayloadSize and maxMessagePayloadSize limits to the underlying Autobahn WebSocketServerFactory, which defaults both to unlimited. No public exploit identified at time of analysis, and EPSS is low (0.07%), but the CVSS:3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N) reflects easy network-reachable abuse against any deployment exposing WebSockets.
Earlier versions of this analysis (2)
Denial of service in Django's Daphne ASGI server before version 4.2.2 allows remote unauthenticated attackers to exhaust server memory by sending oversized WebSocket frames or messages. The flaw stems from Daphne failing to forward maxFramePayloadSize and maxMessagePayloadSize limits to the underlying Autobahn WebSocketServerFactory, which defaults these to unlimited. No public exploit identified at time of analysis, but EPSS scores it at 0.07% and SSVC notes the attack is automatable with partial technical impact.
Unconstrained WebSocket payload handling in daphne before 4.2.2 exposes Django Channels deployments to unauthenticated remote denial of service. The ASGI server failed to forward the maxFramePayloadSize and maxMessagePayloadSize configuration parameters to its underlying Autobahn WebSocketServerFactory, causing Autobahn to operate with its default value of 0 (unlimited) for both limits. Any unauthenticated remote attacker with network access to the WebSocket endpoint can exploit this by streaming arbitrarily large frames or messages, driving unbounded server memory allocation until the process is exhausted or killed. No public exploit has been identified at time of analysis, and the issue is not listed in CISA KEV.
RemediationAI
Upgrade to Daphne 4.2.2 or later, which passes maxFramePayloadSize and maxMessagePayloadSize through to Autobahn's WebSocketServerFactory; consult https://github.com/django/daphne/blob/main/CHANGELOG.txt for the release notes and https://nvd.nist.gov/vuln/detail/CVE-2026-44545 for the advisory. If immediate upgrade is not possible, place Daphne behind a reverse proxy (nginx, HAProxy, Envoy, or a CDN/WAF) configured to enforce a maximum WebSocket frame and message size - note this protects the Daphne process but may break legitimate clients that send large messages such as binary file uploads or media streams. As a secondary control, apply per-IP connection and bandwidth rate limits at the proxy or firewall to slow memory exhaustion attempts, and monitor Daphne worker RSS with alerting so an attack triggers restart/scale-out before the host OOMs.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Daphne is the official ASGI HTTP/WebSocket/HTTP2 server maintained by the Django project, commonly used to serve Django Channels applications. It delegates WebSocket protocol handling to Autobahn|Python's WebSocketServerFactory, which accepts maxFramePayloadSize and maxMessagePayloadSize parameters to bound per-frame and per-message buffer growth. Daphne did not pass these parameters through, so Autobahn fell back to its documented default of 0 (unlimited). This maps cleanly to CWE-770 (Allocation of Resources Without Limits or Throttling): the WebSocket read path accepts attacker-controlled payload sizes without an upper bound, allowing memory to grow until the process or host is starved. The CPE cpe:2.3:a:djangoproject:daphne:*:*:*:*:*:*:*:* confirms the affected product is the upstream djangoproject/daphne package.
Know when Daphne gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network-reachable WebSocket endpoint, no auth or interaction, trivial oversized-frame trigger; impact is pure availability via memory exhaustion with no confidentiality or integrity loss.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
4DescriptionNVD
daphne before 4.2.2 did not pass maxFramePayloadSize or maxMessagePayloadSize to Autobahn's WebSocketServerFactory. Because Autobahn defaults both values to 0 (unlimited), an unauthenticated remote attacker could send arbitrarily large WebSocket messages or frames, causing excessive memory consumption and a denial of service.
Executive ViewAI
Django Daphne is vulnerable to unauthenticated denial-of-service attacks via oversized WebSocket frames that can crash services. No public exploit has been identified, but organizations operating WebSocket-based real-time features must implement immediate protective controls as no vendor patch is currently available.
No vendor-released patch identified at time of analysis. Implement: (1) Autobahn WebSocketServerFactory configuration with explicit maxFramePayloadSize and maxMessagePayloadSize limits (1-2 MB recommended); (2) WebSocket connection rate limiting at reverse proxy/load balancer; (3) WAF rules blocking HTTP upgrade requests with oversized payloads; (4) Monitoring of WebSocket connection logs for anomalous payload patterns; (5) Network ACLs restricting WebSocket endpoint access where operationally feasible.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
EUVD-2026-34091
GHSA-rrc9-mx66-ffcm
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB