CVE-2026-33034: Django DOS Vulnerability

CVE-2026-33034 Overview

A resource exhaustion vulnerability has been discovered in Django affecting versions 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30. ASGI requests with a missing or understated Content-Length header can bypass the DATA_UPLOAD_MAX_MEMORY_SIZE limit when reading HttpRequest.body, allowing remote attackers to load an unbounded request body into memory. This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling).

Critical Impact

Remote attackers can cause denial of service by exhausting server memory through specially crafted ASGI requests that bypass upload size restrictions.

Affected Products

• Django 6.0 before 6.0.4
• Django 5.2 before 5.2.13
• Django 4.2 before 4.2.30
• Unsupported Django series (5.0.x, 4.1.x, 3.2.x) may also be affected

Discovery Timeline

• 2026-04-07 - CVE-2026-33034 published to NVD
• 2026-04-08 - Last updated in NVD database

Technical Details for CVE-2026-33034

Vulnerability Analysis

This vulnerability exists in Django's ASGI request handling mechanism. When processing ASGI requests, Django relies on the Content-Length header to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE configuration setting, which is designed to limit the maximum size of request bodies that can be loaded into memory.

The flaw occurs when an attacker sends an ASGI request with either a missing Content-Length header or one that deliberately understates the actual body size. In these cases, Django fails to properly enforce memory limits when reading HttpRequest.body, allowing attackers to stream arbitrarily large payloads into server memory.

This resource exhaustion vulnerability can lead to denial of service conditions as server memory becomes depleted, potentially affecting all applications and services running on the same host.

Root Cause

The root cause lies in insufficient validation of the Content-Length header during ASGI request processing. Django's memory protection mechanisms rely on this header to pre-validate request sizes before loading the body into memory. When the header is absent or inaccurate, the protection is bypassed entirely, and the full request body is read without enforcing the configured DATA_UPLOAD_MAX_MEMORY_SIZE limit.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Sending HTTP requests to a Django application running under an ASGI server (such as Daphne, Uvicorn, or Hypercorn)
2. Omitting the Content-Length header entirely, or setting it to a value significantly smaller than the actual payload
3. Streaming a large request body to the server
4. Django will read the entire body into memory regardless of the DATA_UPLOAD_MAX_MEMORY_SIZE setting

The vulnerability specifically affects ASGI deployments; traditional WSGI deployments handle content length validation differently and may not be susceptible to this particular attack vector.

Detection Methods for CVE-2026-33034

Indicators of Compromise

• Unusual memory consumption spikes on servers running Django ASGI applications
• High number of incoming HTTP requests with missing or suspiciously small Content-Length headers relative to actual body sizes
• Application crashes or out-of-memory errors in Django ASGI processes
• ASGI server logs showing abnormally large request bodies being processed

Detection Strategies

• Monitor Django application memory usage patterns for anomalies and sudden increases
• Implement request logging at the ASGI server level to track Content-Length header values versus actual received bytes
• Configure alerting on memory threshold breaches for Django application processes
• Review web server access logs for requests with missing or mismatched Content-Length headers

Monitoring Recommendations

• Set up memory usage alerts at 70-80% threshold for early warning detection
• Implement rate limiting at the load balancer or reverse proxy level to throttle suspicious traffic
• Enable detailed ASGI server logging to capture request metadata including header information
• Deploy application performance monitoring (APM) tools to track memory allocation patterns

How to Mitigate CVE-2026-33034

Immediate Actions Required

• Upgrade Django to patched versions: 6.0.4, 5.2.13, or 4.2.30 depending on your current series
• Review Django deployments to identify all ASGI-based applications that may be affected
• Implement request size limits at the reverse proxy or load balancer level as defense-in-depth
• Monitor memory usage on production servers running vulnerable Django versions until patches are applied

Patch Information

Django has released security patches addressing this vulnerability. Users should upgrade to the following fixed versions:

• Django 6.0.x users: Upgrade to 6.0.4 or later
• Django 5.2.x users: Upgrade to 5.2.13 or later
• Django 4.2.x users: Upgrade to 4.2.30 or later

Users on unsupported Django versions (5.0.x, 4.1.x, 3.2.x) should upgrade to a supported and patched version immediately, as these series were not evaluated but may also be affected.

For more information, refer to the Django Weblog Security Releases and the Django Security Release Notes.

Workarounds

• Configure request body size limits at the ASGI server level (Uvicorn, Daphne, Hypercorn) independent of Django settings
• Implement a middleware or reverse proxy rule to reject requests with missing Content-Length headers when large bodies are detected
• Use a reverse proxy like Nginx to enforce client_max_body_size limits before requests reach Django
• Consider temporarily switching to WSGI deployment if ASGI-specific features are not required

# Example Nginx configuration to limit request body size
# Add to server or location block as defense-in-depth

client_max_body_size 10M;

# Reject requests without Content-Length for POST/PUT/PATCH methods
# (requires additional Nginx configuration or lua module)