CVE-2025-64458

What it actually does

The flaw is a denial-of-service condition in Django redirect handling on Windows. When Django constructs redirects through django.http.HttpResponseRedirect, django.http.HttpResponsePermanentRedirect, or django.shortcuts.redirect, certain attacker-controlled redirect destinations containing very large numbers of Unicode characters can trigger expensive NFKC normalization. On affected Django versions, this CPU-intensive processing can tie up worker threads or processes, causing request latency spikes, worker exhaustion, and application unavailability. Affected supported versions are Django 5.1 before 5.1.14, 4.2 before 4.2.26, and 5.2 before 5.2.8; unsupported series such as 5.0.x, 4.1.x, and 3.2.x may also be affected. The issue is most relevant to Django applications running on Windows and accepting user-controlled input that is later used as a redirect target.

Why it matters to the business

Successful exploitation can make affected web applications slow or unavailable without requiring authentication if a public route accepts or derives redirect targets from user input. The main business risk is service disruption: customer-facing downtime, degraded transaction flows, failed login or logout redirects, support load, and potential missed revenue during attacks. Although it is not known to be in CISA KEV and the provided EPSS score is low, the CVSS severity is high for availability impact, and the issue has been public for an extended period, so internet-exposed Django services on Windows should be remediated promptly.

How an attack unfolds

An attacker first identifies a Django endpoint that performs a redirect, such as login, logout, next-page navigation, locale switching, or any route that passes a request parameter into redirect(), HttpResponseRedirect, or HttpResponsePermanentRedirect. The attacker then sends repeated requests where the redirect destination contains an unusually large number of Unicode characters that require costly normalization. On affected Django versions running on Windows, the redirect validation and response construction path spends excessive CPU time normalizing the supplied value. By sending enough concurrent or repeated requests, the attacker can consume available web worker capacity, causing legitimate requests to queue, time out, or fail. No code execution, data theft, or privilege escalation is expected from the flaw itself; the attack goal is availability disruption.

How to fix it

Upgrade Django to a fixed release: 5.2.8 or later for the 5.2 branch, 5.1.14 or later for the 5.1 branch, or 4.2.26 or later for the 4.2 LTS branch. If consuming Django directly from source, ensure the fix corresponding to commit da443c4d5472dfc5afe2567b59123da8372715fe or a later maintained release is present. Unsupported Django branches such as 5.0.x, 4.1.x, and 3.2.x should be migrated to a supported fixed branch rather than relying on unsupported patching. As compensating controls, restrict redirect targets to known relative paths or allowlisted hosts, enforce maximum length limits on redirect-related parameters, reject or normalize suspiciously large Unicode inputs before they reach redirect helpers, and apply rate limiting to unauthenticated redirect endpoints. For environments using vendor packages, apply the vendor-provided fixed package versions where applicable, including Red Hat RHEL EUS 8.1 net-snmp package updates to 1:5.8-12.el8_1.3 if those packages are in scope for the advisory stream; however, the described application-level issue is in Django redirect handling.

How to confirm the fix worked

Confirm the installed Django version is 5.2.8 or later, 5.1.14 or later, or 4.2.26 or later by checking package metadata such as pip show django, python -m django --version, poetry.lock, requirements files, container images, SBOMs, or dependency manifests. For source-based deployments, confirm the code includes the fixed upstream commit or a release containing it. Review application routes for use of django.shortcuts.redirect, HttpResponseRedirect, and HttpResponsePermanentRedirect with user-controlled redirect parameters and verify that length limits and allowlists are enforced. In a staging environment, send oversized Unicode redirect parameters to redirecting endpoints and confirm the application rejects them quickly or handles them without sustained CPU spikes, worker exhaustion, or timeout behavior. Validate that production protections such as WAF/request-size rules, application parameter length limits, and rate limits are active and monitored.

Typical attack path

1. Discover a public Django endpoint that issues redirects or accepts a user-supplied redirect destination such as next, url, redirect, return, continue, or destination.
2. Confirm the application is likely using an affected Django version and, where possible, that it is hosted on Windows.
3. Send crafted requests with very large Unicode-heavy redirect target values to the redirecting endpoint.
4. Repeat the requests or run them concurrently to force expensive normalization work inside Django redirect handling.
5. Exhaust web worker CPU or request-handling capacity, causing slow responses, 5xx errors, gateway timeouts, or service unavailability for legitimate users.

How to detect it

To determine whether exploitation already occurred, review web access logs, reverse proxy logs, WAF events, application logs, APM traces, and host CPU metrics for periods of abnormal latency, request timeouts, worker restarts, or CPU saturation tied to redirecting endpoints. Focus on requests containing very long query strings or POST parameters commonly used for redirects, such as next, url, redirect, return, continue, destination, target, or redirect_uri, especially where values contain large volumes of non-ASCII, percent-encoded UTF-8, or Unicode compatibility characters. In application logs and traces, look for slow transactions or stack samples involving django.shortcuts.redirect, django.http.HttpResponseRedirect, django.http.HttpResponsePermanentRedirect, django.utils.http.url_has_allowed_host_and_scheme, or Python unicodedata.normalize. On Windows-hosted application servers, correlate high Python or web-worker CPU usage with bursts of similar requests from one or more source IPs. Expected signs are availability-focused: high response times, 499/502/503/504 status codes, request queue growth, worker recycling, or watchdog restarts; the vulnerability does not normally leave files, registry keys, persistence mechanisms, or malware artifacts by itself.

• django.shortcuts.redirect
• django.http.HttpResponseRedirect
• django.http.HttpResponsePermanentRedirect
• url_has_allowed_host_and_scheme
• unicodedata.normalize
• next=
• redirect=
• redirect_uri=
• return=
• continue=
• destination=
• target=
• %EF%BC
• %E2%84
• %E3%80
• HTTP 503
• HTTP 504
• upstream timed out
• request timed out
• worker timeout
• Python.exe

What your security team should do

• Prioritize patching internet-facing Django applications running on Windows, especially routes that support login, logout, SSO, password reset, or next/return redirect parameters.
• Upgrade Django to 5.2.8+, 5.1.14+, or 4.2.26+; migrate unsupported Django branches to a supported fixed branch.
• Inventory code for redirect(), HttpResponseRedirect, and HttpResponsePermanentRedirect usage where user input influences the destination.
• Add strict maximum length checks and allowlists for redirect destination parameters, preferring relative paths over arbitrary absolute URLs.
• Deploy or tune rate limits for unauthenticated redirect-heavy endpoints and alert on repeated oversized query strings or request bodies.
• Review web, application, APM, and CPU telemetry for historical spikes correlated with long Unicode-heavy redirect parameters.
• Because this is not currently KEV-listed and has low EPSS, treat it as availability-priority remediation rather than evidence of active exploitation unless local telemetry shows suspicious traffic.