CVE-2024-41990: Django Template Filter DoS Vulnerability

CVE-2024-41990 Overview

CVE-2024-41990 is a denial-of-service vulnerability in the Django web framework. The flaw affects the urlize() and urlizetrunc() template filters, which convert URLs and email addresses in text into clickable links. Attackers can submit very large inputs containing a specific sequence of characters to trigger excessive processing time. The issue impacts Django 5.0 before 5.0.8 and Django 4.2 before 4.2.15.

The vulnerability is categorized under [CWE-130] (Improper Handling of Length Parameter Inconsistency). Exploitation requires no authentication and can be performed remotely over the network against any Django application that renders user-supplied text through the affected filters.

Critical Impact

Remote unauthenticated attackers can cause sustained CPU exhaustion in Django applications, rendering web services unavailable to legitimate users.

Affected Products

• Django 5.0 versions prior to 5.0.8
• Django 4.2 versions prior to 4.2.15
• NetApp products bundling vulnerable Django versions (per NetApp advisory NTAP-20240905-0007)

Discovery Timeline

• 2024-08-06 - Django project releases security advisory and patched versions
• 2024-08-07 - CVE-2024-41990 published to the National Vulnerability Database (NVD)
• 2025-11-04 - Last updated in NVD database

Technical Details for CVE-2024-41990

Vulnerability Analysis

The urlize() and urlizetrunc() template filters scan input text and transform URL-like and email-like substrings into anchor tags. The filters perform multiple passes of regular expression matching and string manipulation on each candidate token. When the input contains very large strings with a specific sequence of characters, processing time grows disproportionately to input size, producing an algorithmic complexity attack.

This is a resource exhaustion flaw that targets CPU rather than memory. The attack does not compromise data confidentiality or integrity but degrades availability of any Django application that exposes templates using urlize on attacker-controlled fields. Common exposure points include comment systems, forum posts, chat messages, and user profile fields rendered with the filter.

Root Cause

The root cause is inefficient string handling within the urlize implementation in django/utils/html.py. The filter tokenizes input and applies repeated transformations to each token. Specific character sequences force the tokenizer into pathological processing paths, causing the per-token cost to scale poorly with input length.

Attack Vector

An attacker submits a crafted payload through any HTTP endpoint that ultimately renders the input through {{ value|urlize }} or {{ value|urlizetrunc:N }}. Typical vectors include form submissions, API request bodies, and message fields. Each request consumes worker process CPU for an extended period, and a small number of concurrent requests can saturate the application server. The vulnerability is described in the Django Weblog Security Update.

No verified public proof-of-concept code is available for this CVE. The Django security team has not published payload details to limit weaponization. Refer to the Django Security Release Notes for additional technical context.

Detection Methods for CVE-2024-41990

Indicators of Compromise

• Sustained high CPU utilization on Django application workers without corresponding traffic increases
• HTTP requests containing unusually large text fields submitted to endpoints that render urlize output
• Worker processes exceeding configured request timeout thresholds on routes that previously responded quickly
• Request bodies several kilobytes or larger targeting comment, message, or profile endpoints

Detection Strategies

• Inspect WSGI or ASGI access logs for requests with abnormally large payload sizes against templated views
• Profile worker process CPU time per request and flag outliers on endpoints that use the urlize or urlizetrunc filters
• Deploy WAF rules limiting request body size on form and API endpoints that accept free-form text
• Audit templates with grep -r "urlize" templates/ to enumerate the application's exposure surface

Monitoring Recommendations

• Alert on application worker CPU saturation paired with elevated request latency on user-content endpoints
• Track 95th and 99th percentile response times per route and investigate sustained regressions
• Monitor worker timeouts, restarts, and 502 or 504 responses from upstream proxies fronting Django
• Log Django version strings from deployment manifests to confirm patch status across environments

How to Mitigate CVE-2024-41990

Immediate Actions Required

• Upgrade Django to version 5.0.8 or 4.2.15, whichever matches the deployed release series
• Inventory all templates using urlize or urlizetrunc and identify those rendering untrusted input
• Enforce strict maximum length limits on form and API fields that flow into affected filters
• Place a reverse proxy or WAF in front of Django to cap request body size and rate-limit text-heavy endpoints

Patch Information

The Django project addressed CVE-2024-41990 in the 5.0.8 and 4.2.15 releases published on August 6, 2024. Upgrade with pip install --upgrade "Django>=4.2.15,<5.0" for the 4.2 series or pip install --upgrade "Django>=5.0.8" for the 5.0 series. Verify the installed version with python -m django --version. Patch details are documented in the Django Weblog Security Update and the NetApp Security Advisory NTAP-20240905-0007.

Workarounds

• Remove urlize and urlizetrunc from templates that render untrusted text until patching is complete
• Truncate user input server-side before it reaches the template layer using model field max_length constraints
• Apply request body size limits at the web server tier, for example client_max_body_size in nginx
• Configure per-request CPU timeouts in the WSGI server, such as --timeout 30 for Gunicorn workers

# Upgrade Django to a patched release
pip install --upgrade "Django>=4.2.15,<5.0"   # 4.2 LTS series
pip install --upgrade "Django>=5.0.8"          # 5.0 series

# Verify the installed version
python -m django --version

# Example nginx limit to reduce attack surface
# Add inside the server or location block:
# client_max_body_size 64k;

# Example Gunicorn worker timeout
gunicorn myproject.wsgi --workers 4 --timeout 30