CVE-2026-5766

What it actually does

This vulnerability affects Django applications handling ASGI requests. When an HTTP request omits the Content-Length header or provides a value smaller than the actual request body size, Django versions before 6.0.5 and 5.2.14 may fail to enforce FILE_UPLOAD_MAX_MEMORY_SIZE as intended. An attacker can send oversized upload bodies that are buffered into application memory, potentially exhausting worker memory, triggering process restarts, increasing latency, or causing partial service unavailability. The issue is a network-accessible denial-of-service condition with low attack complexity, but it requires the application to accept upload-like request bodies over ASGI and lack effective upstream request-size enforcement.

Why it matters to the business

Public-facing Django services that accept file uploads or large request bodies may be disrupted by unauthenticated traffic, causing slow responses, failed uploads, worker crashes, autoscaling events, or temporary outages. Because Django is widely used across web applications and APIs, the operational impact can extend to customer-facing portals, administrative interfaces, and backend services that rely on ASGI request handling. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but the flaw has been public for 96 days, so exposed services should still be upgraded or protected by web-server request-size limits.

How an attack unfolds

An attacker identifies a Django application served through an ASGI stack that accepts POST, PUT, PATCH, or multipart upload requests. The attacker sends requests with either no Content-Length header or a deliberately understated Content-Length value while streaming a much larger body than declared. If the reverse proxy, load balancer, or ASGI server does not enforce a maximum request body size before the request reaches Django, the vulnerable Django request handling path may load excessive data into memory instead of enforcing FILE_UPLOAD_MAX_MEMORY_SIZE. Repeating this across one or more connections can increase memory pressure, degrade response times, cause worker termination by the operating system or container runtime, and reduce application availability. There is no indication from the provided data that this vulnerability enables code execution, data theft, or privilege escalation.

How to fix it

Upgrade affected Django versions to a fixed release: upgrade Django 6.0.x to 6.0.5 or later, and Django 5.2.x to 5.2.14 or later. If running an unsupported Django series such as 5.0.x, 4.1.x, or 3.2.x, migrate to a supported fixed branch because those versions were not evaluated and may also be affected. Do not rely only on Django's FILE_UPLOAD_MAX_MEMORY_SIZE setting for request-size enforcement. Configure request body size limits at the web server, reverse proxy, ingress controller, CDN, load balancer, or ASGI server layer so oversized uploads are rejected before reaching Django. Examples include client_max_body_size for NGINX, LimitRequestBody for Apache HTTP Server, equivalent upload/request-body limits in ingress controllers and API gateways, and application-specific limits in ASGI deployment components. Apply rate limiting and connection timeout controls for upload endpoints to reduce the effectiveness of slow or repeated large-body attacks.

How to confirm the fix worked

Confirm the installed Django version is 6.0.5 or later for the 6.0 branch, or 5.2.14 or later for the 5.2 branch. Validate dependency lockfiles, container images, virtual environments, and deployed artifacts rather than only source manifests. Review web server, ingress, CDN, load balancer, and ASGI server configuration to confirm a maximum request body size is enforced before traffic reaches Django. In a non-production test environment, send upload requests that omit Content-Length or declare a smaller Content-Length than the body size and verify they are rejected at the edge or handled without excessive application memory growth. Monitor application memory, worker restarts, HTTP 413 responses, 5xx rates, and request latency during validation.

Typical attack path

1. Find a Django application exposed over HTTP/S that accepts file uploads or large request bodies.
2. Confirm the application is served through an ASGI deployment path and does not reject oversized bodies at the proxy or application edge.
3. Send a POST, PUT, or PATCH request with a missing Content-Length header or a Content-Length value smaller than the actual streamed body.
4. Continue transmitting a large request body so the vulnerable application path buffers excessive data in memory.
5. Repeat or parallelize requests to increase memory consumption across ASGI workers.
6. Cause degraded performance, worker crashes, container restarts, or temporary application unavailability.

How to detect it

To assess possible prior exploitation, correlate HTTP access logs, reverse proxy logs, load balancer logs, ASGI server logs, application logs, container/runtime events, and host telemetry. Look for bursts of POST, PUT, PATCH, or multipart/form-data requests where Content-Length is missing, zero, unusually small, or inconsistent with bytes received, especially against upload endpoints. Investigate sequences followed by elevated memory usage, worker timeouts, process restarts, container OOM kills, HTTP 500/502/503/504 responses, or sudden latency increases. Useful log sources include NGINX or Apache access/error logs, CDN or WAF request logs, Kubernetes events, container runtime logs, system journal logs, ASGI server logs from uvicorn, daphne, or hypercorn, and application performance monitoring metrics. Because this is a denial-of-service issue, indicators are behavioral rather than unique payload signatures; prioritize time-window correlation between anomalous request-body handling and resource exhaustion.

• Content-Length: 0
• Content-Length: 1
• Transfer-Encoding: chunked
• multipart/form-data
• POST
• PUT
• PATCH
• client intended to send too large body
• Request Entity Too Large
• 413
• upstream prematurely closed connection
• upstream timed out
• worker timeout
• Worker timeout
• Out of memory
• oom-kill
• OOMKilled
• Killed process
• MemoryError
• uvicorn
• daphne
• hypercorn

What your security team should do

• Inventory internet-facing and internal Django applications, prioritizing ASGI deployments that accept uploads or large request bodies.
• Upgrade Django to 6.0.5 or later on the 6.0 branch, or 5.2.14 or later on the 5.2 branch; migrate unsupported Django branches to a supported fixed release.
• Enforce maximum request body size at the reverse proxy, ingress, CDN, load balancer, or web server layer, not only in Django settings.
• Add or verify rate limits, request timeouts, and connection limits for upload endpoints and APIs accepting large bodies.
• Search historical logs for large POST, PUT, PATCH, or multipart requests with missing, zero, or suspiciously small Content-Length values followed by worker restarts, out-of-memory events, or 5xx spikes.
• Alert on repeated oversized upload attempts, malformed Content-Length behavior, abrupt client disconnects during large uploads, and correlated application memory exhaustion.
• Review autoscaling, container memory limits, and restart policies to ensure denial-of-service attempts do not cascade into broader service instability.