CVE-2024-24680: Django intcomma Filter DoS Vulnerability

CVE-2024-24680 Overview

A denial of service vulnerability was discovered in Django's intcomma template filter. The vulnerability affects Django versions 3.2 before 3.2.24, 4.2 before 4.2.10, and 5.0 before 5.0.2. When the intcomma filter is used with very long strings, an attacker can trigger a potential denial-of-service condition, causing the application to become unresponsive or consume excessive resources.

Critical Impact

Attackers can exploit this vulnerability to cause service disruption by sending crafted requests with extremely long strings to Django applications using the intcomma template filter, potentially rendering the application unavailable to legitimate users.

Affected Products

• Django 3.2 before 3.2.24
• Django 4.2 before 4.2.10
• Django 5.0 before 5.0.2

Discovery Timeline

• February 6, 2024 - Django Project releases security patches
• February 6, 2024 - CVE-2024-24680 published to NVD
• November 4, 2025 - Last updated in NVD database

Technical Details for CVE-2024-24680

Vulnerability Analysis

The vulnerability resides in Django's intcomma template filter, which is part of Django's humanize template tags library. This filter is designed to convert integers into strings containing commas separating every three digits, making large numbers more readable. The underlying issue is that the filter does not properly limit the size of input it processes, allowing attackers to supply excessively long strings that consume disproportionate computational resources during processing.

When a very long string is passed to the intcomma filter, the processing algorithm performs operations that scale poorly with input size. This creates an algorithmic complexity vulnerability where legitimate processing time increases dramatically with malicious input length, enabling attackers to exhaust server resources with relatively simple requests.

Root Cause

The root cause of this vulnerability is insufficient input validation in the intcomma template filter implementation. The filter fails to enforce reasonable limits on the length of strings it processes, allowing attackers to trigger resource exhaustion through carefully crafted inputs. This is a classic algorithmic complexity attack vector where the processing cost grows disproportionately to the input size.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending HTTP requests to a Django application that renders templates using the intcomma filter with user-controlled data. The attack can be executed remotely against any publicly accessible Django application that:

1. Uses the intcomma filter from django.contrib.humanize
2. Passes user-supplied or user-influenced data to this filter
3. Does not implement additional input length restrictions

The attacker constructs a request containing an extremely long numeric string that gets processed by the intcomma filter. When the template engine attempts to process this input, it consumes excessive CPU and memory resources, potentially causing the application to become unresponsive to other requests.

Detection Methods for CVE-2024-24680

Indicators of Compromise

• Unusual spikes in CPU utilization on Django application servers
• HTTP requests containing abnormally long numeric strings in parameters or request bodies
• Application response time degradation coinciding with specific request patterns
• Web server logs showing requests with extremely large parameter values targeting template-rendered endpoints

Detection Strategies

• Monitor application performance metrics for sudden CPU or memory spikes that could indicate DoS attempts
• Implement web application firewall (WAF) rules to detect and block requests with excessively long parameter values
• Review Django application logs for repeated requests with unusually large payloads
• Deploy request size limiting at the reverse proxy or load balancer level

Monitoring Recommendations

• Configure alerting thresholds for abnormal resource consumption patterns on Django application servers
• Implement request rate limiting and payload size restrictions at the infrastructure level
• Monitor template rendering performance metrics to detect processing anomalies
• Set up log aggregation to correlate suspicious request patterns across multiple application instances

How to Mitigate CVE-2024-24680

Immediate Actions Required

• Upgrade Django to the patched versions: 3.2.24, 4.2.10, or 5.0.2 or later
• Review application code to identify all usages of the intcomma filter with user-supplied data
• Implement input validation to limit string length before passing data to the intcomma filter
• Consider deploying rate limiting at the web server or load balancer level as a temporary measure

Patch Information

Django Project has released security patches addressing this vulnerability. The fixes are included in Django versions 3.2.24, 4.2.10, and 5.0.2. Organizations should upgrade to these patched versions immediately. Detailed information about the security releases is available in the Django Security Releases Documentation and the Django Weblog Security Releases. Fedora users should also check the Fedora Package Announcements for distribution-specific updates.

Workarounds

• Implement application-level input validation to reject strings exceeding reasonable length thresholds before they reach the template layer
• Configure web server request body size limits to prevent extremely large payloads from reaching the application
• Add custom template filters that pre-validate input length before delegating to intcomma
• Deploy rate limiting rules to restrict the number of requests from individual IP addresses

# Configuration example - Nginx request body size limit
# Add to nginx.conf or server block
client_max_body_size 1m;
client_body_buffer_size 16k;

# Rate limiting configuration
limit_req_zone $binary_remote_addr zone=django_limit:10m rate=10r/s;
limit_req zone=django_limit burst=20 nodelay;