CVE-2025-14550

What it actually does

The flaw is a remotely triggerable denial-of-service condition in Django's ASGI request handling. In affected Django versions, ASGIRequest can mishandle crafted requests containing many duplicate HTTP headers, causing excessive processing, memory pressure, worker exhaustion, or request-handling failure. The issue affects Django 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28; unsupported older branches such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and should be treated as potentially affected if ASGI deployments are still in use. The impact is limited to availability; the vulnerability does not directly provide code execution, data disclosure, or privilege escalation.

Why it matters to the business

Public-facing Django applications running affected versions can be made slow or unavailable by unauthenticated remote traffic. For organizations that rely on Django-backed APIs, web portals, or internal services, exploitation could cause outages, failed transactions, degraded customer experience, alert fatigue, and increased infrastructure costs from autoscaling or worker restarts. The CVSS score is high for availability impact, but EPSS is currently low and there is no known CISA KEV listing or ransomware association, so remediation should be prioritized based on internet exposure and service criticality rather than evidence of active mass exploitation.

How an attack unfolds

An attacker identifies a Django application served through an ASGI stack, such as Uvicorn, Daphne, Hypercorn, or another ASGI-compatible deployment path. They then send specially crafted HTTP requests containing multiple duplicate headers. Because the vulnerable ASGIRequest processing path does not safely handle this header pattern, the application may consume excessive resources or fail while parsing or normalizing the request. By repeating the request at volume or targeting endpoints handled by the affected ASGI application, the attacker can exhaust application workers, increase latency, trigger errors, or cause service unavailability. Authentication is not required, and the attacker does not need user interaction or access to valid application data.

How to fix it

Upgrade Django to a fixed release: 6.0.2 or later for the 6.0 branch, 5.2.11 or later for the 5.2 branch, and 4.2.28 or later for the 4.2 LTS branch. If tracking Django directly from Git, include commit ba00558ddac694d92b05d12ecd2a5b7fcc1de025 or a later safe revision. For MinimOS traefik-3 packaging, upgrade to 3.6.2-r1 or later where applicable. Migrate unsupported Django branches, including 5.0.x, 4.1.x, and 3.2.x, to a supported fixed branch because they were not evaluated and may remain vulnerable. As compensating controls until patching is complete, enforce reasonable maximum header counts and header sizes at the reverse proxy, load balancer, WAF, or ASGI server; enable request rate limiting; restrict access to non-public services; and ensure worker process supervision automatically recovers unhealthy processes.

How to confirm the fix worked

Confirm application dependencies and runtime versions after deployment. Use package manifests, lockfiles, container image SBOMs, and runtime checks such as `python -m django --version`, `pip show Django`, or `python -c "import django; print(django.get_version())"` to verify that Django is at 6.0.2, 5.2.11, 4.2.28, or later. Confirm that unsupported branches are no longer deployed. Validate that production images and virtual environments were rebuilt rather than only source files updated. In a staging environment, send benign requests with duplicate headers through the same proxy and ASGI path and confirm the application responds normally or rejects the request at the edge without worker exhaustion. Review reverse proxy, WAF, and ASGI server configuration to ensure header count, header size, timeout, and rate-limit controls are active.

Typical attack path

1. Scan for internet-facing Django applications or services likely using an ASGI deployment stack.
2. Send test HTTP requests containing many duplicate header fields to determine whether the service slows down, errors, or resets connections.
3. Increase request rate or header count to amplify CPU, memory, or worker exhaustion.
4. Sustain the traffic against one or more endpoints until application workers become saturated or the service becomes unavailable.
5. Optionally rotate source addresses or route through proxies to bypass simple IP-based rate limits.

How to detect it

Investigate historical exploitation by reviewing reverse proxy, load balancer, CDN, WAF, ASGI server, application, and infrastructure telemetry for signs of header-based denial-of-service activity. Useful sources include NGINX, Apache, Envoy, HAProxy, Traefik, CDN/WAF request logs, Uvicorn/Daphne/Hypercorn logs, Django application logs, container orchestration events, process supervisor logs, APM traces, and host metrics. Look for bursts of requests from one or many sources with unusually large numbers of headers, repeated header names, high request-header byte counts, HTTP 400 or 431 responses, upstream 499/502/503/504 errors, worker timeouts, process restarts, memory growth, CPU saturation, and sudden latency spikes affecting ASGI-served endpoints. Because the attack payload can use arbitrary duplicate header names, there is no single reliable malicious string; detections should focus on behavioral patterns such as repeated header keys, excessive header counts, and resource exhaustion temporally correlated with inbound requests. If packet captures, full-fidelity HTTP logs, or WAF samples are available, inspect requests immediately preceding outages for duplicate header fields appearing many times in the same request.

What your security team should do

• Inventory all Django applications, containers, and services, prioritizing internet-facing ASGI deployments.
• Upgrade affected Django versions to 6.0.2, 5.2.11, 4.2.28, or later, and rebuild/redeploy all dependent application images.
• Treat unsupported Django branches as potentially vulnerable and migrate them to a supported fixed branch rather than relying on compensating controls alone.
• Apply edge controls for maximum HTTP header count, maximum header size, request body/header timeouts, and per-source rate limits.
• Monitor for abnormal spikes in requests with duplicate headers, HTTP 400/431/500 responses, upstream timeouts, worker restarts, memory pressure, and latency increases.
• Add load balancer, reverse proxy, and WAF detections for requests containing unusually high numbers of repeated header names.
• Perform post-remediation validation using dependency scans, runtime version checks, and controlled duplicate-header testing in staging.