CVE-2026-25673

What it actually does

Django URLField.to_python() invokes Python urllib.parse.urlsplit() while converting and validating URL input. On Windows, urlsplit() performs Unicode NFKC normalization that can become disproportionately slow for large URL strings containing certain Unicode characters. A remote, unauthenticated attacker can submit oversized crafted URL values to any reachable Django form, API, admin, or validation path that uses URLField, causing worker threads or processes to spend excessive CPU time in URL parsing. The impact is denial of service through application latency, worker exhaustion, queue buildup, and availability loss; confidentiality and integrity are not directly affected.

Why it matters to the business

Public-facing Django applications that accept URL input can be slowed or made unavailable by repeated malicious submissions, especially when hosted on Windows. This can disrupt customer transactions, administrative workflows, APIs, and dependent services, and may require emergency scaling or traffic blocking. Although this issue is not currently listed in CISA KEV and has low EPSS, it is network-exploitable without authentication or user interaction and has a high availability impact, so internet-exposed URL submission paths should be prioritized for patching.

How an attack unfolds

An attacker first identifies a Django application endpoint that accepts URL-like input, such as a profile website field, webhook configuration, link submission form, admin object form, REST API serializer backed by URL validation, or any custom code using Django URLField. The attacker sends very large URL values containing Unicode characters that trigger slow NFKC normalization in Python urlsplit() on Windows. When Django converts the field value through URLField.to_python(), the application worker spends excessive CPU time parsing the input before it can reject or accept the request. By repeating the request concurrently, the attacker ties up available workers, increases response latency, fills request queues, and can make the service unavailable to legitimate users. No credentials, prior access, or successful data modification are required.

How to fix it

Upgrade Django to a fixed supported release: 6.0.3 or later for the 6.0 series, 5.2.12 or later for the 5.2 LTS series, or 4.2.29 or later for the 4.2 LTS series. Unsupported Django branches such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and should be upgraded to a supported fixed branch rather than relied upon. If immediate upgrade is not possible, reduce exposure by enforcing maximum request body and field lengths, rejecting excessively long URL inputs before Django URLField validation, applying per-IP and per-route rate limits, using WAF/API gateway rules for anomalously large Unicode URL parameters, and increasing worker isolation/timeouts to limit blast radius. Windows-hosted Django deployments that process untrusted URL input should be treated as highest priority.

How to confirm the fix worked

Confirm the installed Django version is 6.0.3 or later, 5.2.12 or later, or 4.2.29 or later using package inventory, lockfiles, container images, and runtime checks such as python -m django --version or django.get_version(). Verify that all deployed artifacts, virtual environments, containers, and build caches use the patched version and that unsupported Django series have been retired. Review externally reachable forms and APIs for URLField, model URLField, serializers, and custom validation code that ultimately calls Django URL validation. In staging, test with oversized invalid URL inputs and confirm requests are rejected quickly, request-size limits are enforced, and application workers do not show sustained CPU spikes or long request durations. Validate compensating controls by confirming gateway/WAF limits, application timeouts, and rate limits trigger before expensive validation occurs.

Typical attack path

1. Discover a Django endpoint that accepts or validates URL input.
2. Confirm the endpoint reaches Django URLField validation or equivalent form/model validation.
3. Send an oversized URL value containing problematic Unicode characters to the vulnerable parameter.
4. Cause Django on Windows to spend excessive CPU time in urllib.parse.urlsplit() during URLField.to_python().
5. Repeat requests in parallel to exhaust worker capacity and degrade or deny service.
6. Maintain pressure until traffic is blocked, rate-limited, scaled, or the application is patched.

How to detect it

There is no known unique compromise artifact for this denial-of-service issue, so detection should focus on behavioral evidence around URL-submission endpoints. Review web server, reverse proxy, WAF, load balancer, application, APM, and infrastructure telemetry for bursts of requests containing very large URL parameters or form fields with non-ASCII Unicode characters, especially from repeated source IPs or distributed clients. Correlate those requests with elevated CPU usage on application workers, long request durations, worker recycling, request timeouts, queue depth increases, and elevated 4xx/5xx responses. Application logs may show slow requests or validation failures around forms, serializers, model saves, or endpoints that accept URL fields, but the malicious payload may be truncated by logging systems. For forensics, preserve raw access logs and request metadata where lawful and configured, because default logs may not capture POST bodies. Distinguish exploitation from normal traffic by looking for repeated oversized URL-field submissions immediately preceding availability degradation rather than isolated validation errors.

What your security team should do

• Patch Django to 6.0.3+, 5.2.12+, or 4.2.29+ across all applications, images, and build pipelines, prioritizing internet-facing services on Windows.
• Inventory URL input surfaces, including forms, admin pages, APIs, webhook settings, and model/serializer fields that use Django URLField or equivalent URL validation.
• Add request-size, parameter-length, and rate-limit controls for URL submission endpoints, especially where unauthenticated users can submit data.
• Monitor for spikes in CPU utilization, request latency, 408/429/499/500-class errors, worker timeouts, and repeated large Unicode-bearing requests to URL validation routes.
• Block or challenge abusive clients sending unusually large URL fields or high volumes of failed URL submissions.
• Migrate unsupported Django branches to a supported fixed release rather than attempting partial backports without vendor support.
• Ensure operational runbooks include rapid traffic throttling or endpoint disablement for URL-submission functionality during active denial-of-service attempts.