CVE-2026-5766: Djangoproject Django DOS Vulnerability

CVE-2026-5766 Overview

CVE-2026-5766 is a denial of service vulnerability in the Django web framework affecting versions 6.0 before 6.0.5 and 5.2 before 5.2.14. The flaw allows ASGI requests with a missing or understated Content-Length header to bypass the FILE_UPLOAD_MAX_MEMORY_SIZE limit. Attackers can submit oversized file uploads that load into memory, causing service degradation. The vulnerability is tracked under [CWE-130: Improper Handling of Length Parameter Inconsistency]. Django credits Kyle Agronick for reporting the issue. Earlier unsupported series including 5.0.x, 4.1.x, and 3.2.x were not evaluated and may also be affected.

Critical Impact

Remote unauthenticated attackers can exhaust server memory by sending crafted ASGI uploads, leading to denial of service against Django applications.

Affected Products

• Django 6.0 before 6.0.5
• Django 5.2 before 5.2.14
• Earlier unsupported series (5.0.x, 4.1.x, 3.2.x) potentially affected

Discovery Timeline

• 2026-05-05 - Django releases security patch and publishes advisory
• 2026-05-05 - CVE-2026-5766 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-5766

Vulnerability Analysis

The vulnerability resides in Django's ASGI request handling path for multipart file uploads. Django enforces FILE_UPLOAD_MAX_MEMORY_SIZE to determine when an upload is buffered in memory versus written to disk. Under ASGI, when a client omits the Content-Length header or sends a value smaller than the actual body size, Django fails to apply the in-memory limit correctly. The framework continues reading streamed body chunks into memory beyond the configured threshold.

This behavior maps to [CWE-130: Improper Handling of Length Parameter Inconsistency]. An attacker exploits the mismatch between the declared and actual transfer length to force the application server to allocate large amounts of memory per request. Repeated requests can exhaust available memory and degrade or crash the worker process.

Root Cause

The root cause is incomplete validation of the request body size in the ASGI handler. Django relied on Content-Length to gate memory buffering against FILE_UPLOAD_MAX_MEMORY_SIZE. When the header is missing or understated, the size check is bypassed during chunked or streamed reads. The Django security team reiterates that operators should also configure request size limits at the web server or reverse proxy layer.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker sends an HTTP POST request to any Django endpoint that accepts file uploads while running under an ASGI server such as Daphne or Uvicorn. The request omits Content-Length or provides a falsely low value, then streams a large multipart body. The Django ASGI handler buffers the data in memory, bypassing the configured upload size limit. Refer to the Django Weblog Security Releases for technical details.

Detection Methods for CVE-2026-5766

Indicators of Compromise

• ASGI access logs showing POST requests with missing Content-Length headers and unusually long processing times.
• Worker processes consuming memory significantly above baseline during multipart uploads.
• Repeated 5xx errors or worker restarts correlated with upload endpoints.
• Spikes in chunked transfer-encoded POST requests targeting upload-handling views.

Detection Strategies

• Inspect reverse proxy and application logs for requests lacking Content-Length or using Transfer-Encoding: chunked against Django upload routes.
• Monitor Python process memory growth per request using application performance monitoring agents.
• Alert on Django worker OOM kills or systemd restarts on hosts running Daphne, Uvicorn, or Hypercorn.

Monitoring Recommendations

• Track request body sizes at the WAF or reverse proxy level and flag mismatches with declared Content-Length.
• Establish a baseline for memory consumption of ASGI workers and trigger alerts on sustained deviation.
• Forward web server and Django logs to a centralized analytics platform for correlation against CVE-2026-5766 patterns.

How to Mitigate CVE-2026-5766

Immediate Actions Required

• Upgrade Django to version 6.0.5 or 5.2.14 in all production environments.
• Audit deployments running unsupported Django series (5.0.x, 4.1.x, 3.2.x) and plan upgrades to a supported release.
• Enforce request body size limits at the web server, reverse proxy, or load balancer layer.
• Restart ASGI workers after applying the patch to ensure the fix is loaded.

Patch Information

Django released fixed versions 6.0.5 and 5.2.14 on May 5, 2026. Details and download links are available in the Django Security Release Notes and the Django Weblog Security Releases. Apply the upgrade through your dependency manager and redeploy ASGI services.

Workarounds

• Configure a maximum request body size in the front-end web server (for example, client_max_body_size in nginx) to reject oversized uploads before they reach Django.
• Place Django ASGI services behind a reverse proxy that validates Content-Length and rejects malformed or chunked requests where not required.
• Restrict access to upload endpoints with authentication or rate limiting until patched versions are deployed.

# Example nginx configuration to enforce a request size limit
http {
    client_max_body_size 10m;

    server {
        listen 443 ssl;
        server_name app.example.com;

        location / {
            proxy_pass http://django_asgi_upstream;
            proxy_set_header Host $host;
            proxy_request_buffering on;
        }
    }
}