CVE-2026-33034

What it actually does

CVE-2026-33034 is a network-exploitable denial-of-service flaw in Django’s ASGI request handling. In affected versions, requests with a missing or understated Content-Length header can bypass Django’s DATA_UPLOAD_MAX_MEMORY_SIZE enforcement when application code reads HttpRequest.body. This can cause Django to read an unbounded request body into process memory, allowing an unauthenticated remote attacker to exhaust memory and degrade or crash application workers. The issue affects Django 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30; older unsupported branches such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and may also be affected.

Why it matters to the business

Successful exploitation can make Django-backed services slow, unstable, or unavailable by exhausting application server memory. Public ASGI deployments are most exposed, especially APIs or endpoints that read raw request bodies, accept uploads, webhooks, or large POST/PUT/PATCH requests. Although this vulnerability does not directly expose data or allow code execution, it can interrupt revenue-generating applications, customer portals, administrative workflows, and integrations. The CVSS score is high for availability impact, but EPSS is currently low and it is not listed in CISA KEV, so remediation should be prioritized based on internet exposure and service criticality rather than evidence of widespread exploitation.

How an attack unfolds

An attacker identifies a Django application running on an affected version behind an ASGI stack. They then send HTTP requests to an endpoint that causes the application to access HttpRequest.body, while omitting Content-Length or declaring a smaller Content-Length than the body actually sent. Because vulnerable Django versions rely on that header path for upload memory limit enforcement, the configured DATA_UPLOAD_MAX_MEMORY_SIZE limit may not be applied correctly. The application process continues reading request data into memory until memory pressure becomes severe, causing worker termination, container eviction, process restarts, latency spikes, or full service unavailability. Repeating the requests across workers or instances can amplify the denial-of-service effect.

How to fix it

Upgrade Django to a fixed release: 6.0.4 or later for the 6.0 series, 5.2.13 or later for the 5.2 series, or 4.2.30 or later for the 4.2 LTS series. Applications on unsupported Django branches should move to a supported fixed branch because older series were not fully evaluated and may be vulnerable. Rebuild and redeploy application images after upgrading dependencies, and confirm lockfiles and runtime packages reflect the fixed version. As defense in depth, enforce request body size limits at the edge and application gateway layer, such as reverse proxies, load balancers, WAFs, API gateways, and ASGI servers. Configure limits such as nginx client_max_body_size, Apache LimitRequestBody, ingress-controller body-size limits, API gateway payload limits, and WAF rules that reject oversized, malformed, chunked, or suspicious requests. Rate-limit large request methods and restrict unauthenticated upload or webhook endpoints where possible. Do not rely solely on Django’s DATA_UPLOAD_MAX_MEMORY_SIZE in affected versions as the primary mitigation.

How to confirm the fix worked

Confirm the deployed Django runtime version is fixed by checking package metadata, dependency lockfiles, container images, and running application environments. Common checks include `python -m django --version`, `pip show Django`, `pip freeze | grep -i Django`, Poetry/Pipenv lockfile inspection, and SBOM or image scans. Verify that no deployed service is running Django 6.0.x below 6.0.4, 5.2.x below 5.2.13, 4.2.x below 4.2.30, or unsupported branches. Confirm ASGI-facing services have independent request-size enforcement at the proxy, gateway, or ingress layer. Validate operationally by reviewing configuration for request body limits and by performing controlled, authorized negative testing to ensure oversized or malformed-body requests are rejected before reaching Django and do not increase worker memory unexpectedly.

Typical attack path

1. Identify an internet-accessible Django application or API likely served through ASGI.
2. Probe for endpoints that accept POST, PUT, PATCH, uploads, webhooks, or raw-body parsing.
3. Send requests with missing, zero, or understated Content-Length headers while streaming a large body.
4. Trigger application code paths that read HttpRequest.body.
5. Cause excessive memory allocation in affected Django workers.
6. Repeat or parallelize requests until workers crash, containers are killed, or the service becomes unavailable.

How to detect it

There is no single definitive indicator that proves exploitation, so detection should focus on correlated evidence: unusual large request traffic, malformed request headers, application memory spikes, worker crashes, and OOM events. Review reverse proxy, load balancer, API gateway, WAF, ASGI server, application, container runtime, and host kernel logs. Look for bursts of POST, PUT, or PATCH requests where Content-Length is absent, zero, unusually small compared with bytes received, or combined with chunked transfer behavior. Correlate those requests with increased resident memory, process restarts, HTTP 500/502/503/504 responses, upstream disconnects, container OOMKilled events, kernel OOM-killer messages, and Django or ASGI worker exceptions. Pay particular attention to unauthenticated endpoints that read raw request bodies, upload handlers, webhook receivers, and API endpoints. If logs include request size fields, compare received byte counts against Content-Length and configured gateway body limits. If exploitation is suspected, preserve access logs, WAF logs, application logs, container events, process memory metrics, and any core dumps before restarting or redeploying systems.

• MemoryError
• Out of memory: Killed process
• oom-killer
• OOMKilled
• Killed process
• worker timeout
• worker restart
• upstream prematurely closed connection
• upstream timed out
• client intended to send too large body
• request body too large
• Content-Length: 0
• Transfer-Encoding: chunked
• POST
• PUT
• PATCH
• HttpRequest.body
• DATA_UPLOAD_MAX_MEMORY_SIZE
• RequestDataTooBig
• daphne
• uvicorn
• hypercorn
• gunicorn

What your security team should do

• Inventory all Django applications, containers, and serverless packages, prioritizing internet-facing ASGI deployments.
• Upgrade affected Django versions to 6.0.4, 5.2.13, 4.2.30, or later as appropriate.
• Migrate unsupported Django branches to a supported fixed release line.
• Enforce request body size limits at reverse proxies, load balancers, ingress controllers, API gateways, and WAFs.
• Prioritize services with unauthenticated POST, PUT, PATCH, upload, webhook, or raw-body endpoints.
• Monitor memory usage, worker restarts, container OOM kills, and spikes in malformed or large request traffic.
• Add SIEM detections for POST/PUT/PATCH requests with missing, zero, or inconsistent Content-Length values where logs support it.
• Review recent availability incidents for symptoms consistent with memory exhaustion following unusual request traffic.
• Ensure dependency scanners and CI/CD gates flag vulnerable Django versions before deployment.