CVE-2015-0222

What it actually does

A flaw in Django's ModelMultipleChoiceField allows an unauthenticated remote attacker to trigger a denial of service. When the 'show_hidden_initial' property is set to True for this field, submitting a request with duplicate values for the field causes the application to execute a separate SQL query for each submitted value. A large number of duplicate values will generate a correspondingly large number of SQL queries, overwhelming the database and application server, leading to resource exhaustion and making the application unresponsive.

Why it matters to the business

Exploitation of this vulnerability can lead to a denial of service, making the web application unavailable to legitimate users. This can result in business disruption, loss of revenue for e-commerce sites, and damage to the organization's reputation. Since the vulnerable Django versions are very old and unsupported, applications running them are likely exposed to numerous other high-risk vulnerabilities, compounding the overall business risk.

How an attack unfolds

An attacker first identifies a target website using a vulnerable version of Django (1.6.x before 1.6.10 or 1.7.x before 1.7.3). The attacker then locates a form on the site that uses a ModelMultipleChoiceField. Through inspection of the page source or by observing form behavior, they determine if the 'show_hidden_initial' property is enabled. The attacker then crafts a simple HTTP POST request to the form's submission endpoint, including a large number of duplicate values for the vulnerable field. The Django backend, upon receiving this request, will process each duplicate value individually, launching a flood of SQL queries against the database. This query storm consumes server resources, effectively knocking the application offline.

How to fix it

The primary and most effective remediation is to upgrade Django to a patched version. For projects on the 1.6.x branch, upgrade to version 1.6.10 or later. For projects on the 1.7.x branch, upgrade to version 1.7.3 or later. As these versions are extremely old and no longer receive security support, a full upgrade to a currently supported Django LTS version is strongly recommended to address this and many other vulnerabilities.

How to confirm the fix worked

To confirm remediation, verify that the Django version installed in your application's environment is 1.6.10 or higher, 1.7.3 or higher, or a modern, non-vulnerable version (e.g., 1.8+). This can be checked using package management tools like `pip show django` or by inspecting the application's dependency files. To check for exposure, audit your codebase for the use of `ModelMultipleChoiceField` in conjunction with `show_hidden_initial=True` in forms.py or views.py files.

Typical attack path

1. Attacker identifies a web application running a vulnerable version of Django (1.6.x or 1.7.x).
2. Attacker discovers a form using a ModelMultipleChoiceField with the 'show_hidden_initial' property set to True.
3. Attacker crafts and sends an HTTP request containing a large number of duplicate values for the identified field.
4. The Django application server receives the malicious request and begins processing the input.
5. For each duplicate value, the server executes a distinct SQL query, leading to a query flood.
6. The database and/or web server become overloaded, causing a denial of service for all users.

How to detect it

To detect potential exploitation, monitor for abnormal resource utilization spikes (CPU, memory, database connections) on your web and database servers. Correlate these spikes with incoming web traffic. Examine web server access logs for an unusual number of POST requests to a specific form endpoint, where the request body size is large or contains a high count of repeated parameter names and values. In database logs, search for a rapid succession of identical or very similar SELECT queries originating from a single web server process during the time of the performance degradation.

What your security team should do

• Immediately identify all applications using Django and audit their versions. Prioritize patching or upgrading any application running Django 1.6.x or 1.7.x.
• Upgrade vulnerable applications to at least Django 1.6.10 or 1.7.3. Plan a full migration to a modern, supported Django LTS release to mitigate systemic risk from running end-of-life software.
• Consider implementing rate-limiting at the web server or WAF level to mitigate the impact of DoS attacks that involve a high volume of requests or parameters from a single source.
• Review application code to limit or remove the use of `show_hidden_initial=True` with `ModelMultipleChoiceField` as a defense-in-depth measure.