CVE-2024-27351

What it actually does

This is a Regular Expression Denial of Service (ReDoS) vulnerability. A specially crafted string, when processed by the `django.utils.text.Truncator.words()` method (with `html=True`) or the `truncatewords_html` template filter, can cause catastrophic backtracking in the regular expression engine. This leads to excessive CPU consumption, making the application process or thread unresponsive and resulting in a denial of service.

Why it matters to the business

An attacker can render the web application or service unavailable to legitimate users. This downtime can lead to direct financial loss, operational disruption, and damage to the organization's reputation. Since the vulnerability can be triggered wherever user-supplied HTML content is truncated for display, it poses a risk to applications with features like comment sections, forums, or user profiles.

How an attack unfolds

An attacker identifies a Django application that uses the vulnerable text truncation functions on user-provided content. The attacker then submits a carefully crafted string, likely through a web form such as a blog comment or a user profile update. When the application attempts to process and display this string by truncating it, the flawed regular expression is triggered. This causes the server's CPU to spike for the worker process handling the request, effectively freezing it. By sending a few such requests, an attacker can exhaust all available application server resources, leading to a complete denial of service for all users.

How to fix it

The most effective remediation is to upgrade to a patched version of Django. Administrators should upgrade their instances to the following versions or later: - Django 3.2 users should upgrade to version 3.2.25. - Django 4.2 users should upgrade to version 4.2.11. - Django 5.0 users should upgrade to version 5.0.3. For systems using affected downstream packages, such as `cockpit-dashboard` on AlmaLinux 8, update to the fixed version (e.g., `224.2-1.el8`). If upgrading is not immediately possible, consider mitigating the risk by auditing code for uses of `truncatewords_html` and `Truncator.words(html=True)` and disabling them if they process untrusted input. However, upgrading is the strongly recommended solution.

How to confirm the fix worked

To validate the fix, first verify that the Django package has been upgraded to a non-vulnerable version (3.2.25+, 4.2.11+, or 5.0.3+). This can be done by running `pip freeze | grep Django` in the application's environment. To confirm the vulnerability is patched, a test case with a known ReDoS payload for this vulnerability can be run in a pre-production environment. On a patched system, the payload will be handled without causing a CPU spike or service interruption.

Typical attack path

1. The attacker identifies a web application built with a vulnerable version of Django.
2. The attacker locates an input field (e.g., comment box, forum post, user profile) that accepts HTML and is later truncated for display using `truncatewords_html` or a similar function.
3. The attacker submits a malicious string designed to exploit the inefficient regular expression.
4. The server processes the malicious string, triggering the ReDoS condition.
5. The worker process handling the request consumes 100% CPU and becomes unresponsive.
6. By repeating the request, the attacker can tie up all server resources, causing a complete denial of service.

How to detect it

Detecting exploitation of this vulnerability involves monitoring for performance degradation. Check Application Performance Monitoring (APM) data and server monitoring tools for sustained periods of high CPU utilization tied to specific application worker processes. Correlate these CPU spikes with incoming requests in web server access logs, paying close attention to requests to endpoints that handle user-generated content. Look for application logs indicating worker timeouts, gateway timeouts (504 errors), or other signs of unresponsiveness. The malicious input string may be present in logs or stored in the database, though it may be difficult to distinguish from benign complex strings without a known pattern.

What your security team should do

• Immediately identify all Django applications in your environment and upgrade those running vulnerable versions (3.2 < 3.2.25, 4.2 < 4.2.11, 5.0 < 5.0.3) to a patched release.
• If patching is delayed, conduct a code review to find all instances of `truncatewords_html` and `Truncator.words(html=True)`. Prioritize disabling or adding strict input validation for instances that process untrusted user content.
• Configure monitoring and alerting for sustained high CPU utilization on Django application servers, which could indicate an attempted ReDoS attack.