CVE-2015-0221

What it actually does

The vulnerability exists in the `django.views.static.serve` view, which reads files line-by-line into memory. When a remote attacker requests a file containing a single, extremely long line, the Django process attempts to load the entire line into memory. This leads to excessive memory consumption, causing the process to become unresponsive or be terminated by the operating system, resulting in a denial of service.

Why it matters to the business

An attacker can render the web application or website completely unavailable to legitimate users. This service outage can damage brand reputation, erode user trust, and lead to direct financial loss if the application is revenue-generating. The application will appear crashed or unresponsive to all users until it is manually restarted.

How an attack unfolds

An attacker first uploads or otherwise places a file containing a single, very long line of text onto the target server. This file must be in a directory served by Django's static file view, which is common in development environments but insecure in production. The attacker then makes a simple HTTP GET request for that file. The vulnerable Django application attempts to serve the file, reads the excessively long line, exhausts its memory allocation, and crashes or hangs, successfully denying service to all other users.

How to fix it

Upgrade Django to a patched version: 1.4.18 or later, 1.6.10 or later, or 1.7.3 or later. It is strongly recommended to upgrade to a modern, supported version of Django. As a best practice, do not use `django.views.static.serve` in production environments. Instead, configure a dedicated web server such as Nginx or Apache to serve static files, as this is more secure and performant.

How to confirm the fix worked

To validate the fix, verify that the Django version installed in your environment is a patched version (e.g., 1.4.18+, 1.6.10+, 1.7.3+, or a newer major release). To test for exposure in a non-production environment, create a file with a single, very long line, place it in a static directory, and request it. A vulnerable system will exhibit a significant memory spike and may crash, while a patched system will handle the request without issue.

Typical attack path

1. The attacker identifies a web application running a vulnerable version of Django.
2. The attacker finds a method to place a file with an extremely long line in a directory served by `django.views.static.serve`.
3. The attacker sends a standard HTTP GET request for the malicious file's URL.
4. The Django server attempts to read the file, causing its memory usage to spike dramatically.
5. The application process is terminated by the OS or becomes unresponsive, resulting in a denial of service for all users.

How to detect it

Review web server access logs for HTTP GET requests to static files that are correlated with application crashes, HTTP 5xx errors, or service timeouts. Check system and application monitoring tools for anomalous memory consumption spikes in the Django/WSGI process (e.g., Gunicorn, uWSGI) that coincide with these requests. Forensically examine the filesystem, particularly in directories that allow user uploads, for text-based files with unusually large sizes or files containing a single, extremely long line of characters.

• Web server access log entries showing GET requests for static files immediately followed by 5xx errors or service unavailability.
• Files on the server containing a single line of text exceeding a typical buffer size (e.g., > 8KB).

What your security team should do

• Prioritize upgrading all applications using affected Django versions to a patched and supported release.
• Audit all production Django applications to ensure they are not using `django.views.static.serve`. This view is not hardened for production use.
• Configure a dedicated web server like Nginx or Apache to handle static file serving in production environments.
• Implement resource monitoring and alerting on web application processes to detect abnormal memory consumption, which can be an indicator of a denial-of-service attack.