CVE-2025-64459

What it actually does

The vulnerability is a SQL injection flaw within the Django Object-Relational Mapper (ORM). Specific methods (`QuerySet.filter()`, `QuerySet.exclude()`, `QuerySet.get()`) and the `Q()` class fail to properly sanitize input when a dictionary is expanded and passed to the `_connector` argument. This allows an attacker to inject arbitrary SQL syntax into the database query, leading to unauthorized data access, modification, deletion, and potentially remote code execution on the database server, bypassing the application's intended logic.

Why it matters to the business

This critical vulnerability allows an attacker to bypass all application-level security controls and directly interact with the underlying database. The consequences include the theft of sensitive data such as customer PII, financial records, and intellectual property; fraudulent data modification; and service disruption through data deletion. A successful exploit can lead to severe reputational damage, regulatory fines, and a complete loss of customer trust. The availability of a public exploit significantly increases the likelihood of an attack, making this a high-priority issue.

How an attack unfolds

An attacker first identifies a web application using a vulnerable version of Django. They then probe the application to find an endpoint where user-controlled input can influence the construction of a dictionary that is subsequently passed to a `QuerySet` method using dictionary expansion (`**kwargs`). The attacker crafts a malicious dictionary where the keys and values contain SQL injection payloads. When this dictionary is passed to the vulnerable `_connector` argument, the ORM constructs a SQL query containing the attacker's malicious code. This allows the attacker to execute arbitrary commands against the database, such as reading sensitive data from the `users` table, modifying records, or exfiltrating the entire database.

How to fix it

The most effective remediation is to upgrade Django to a patched version. Developers should upgrade to version 5.1.14, 4.2.26, 5.2.8, or newer. For projects using unsupported Django series (e.g., 5.0.x, 4.1.x), it is critical to upgrade to a supported major version and then apply the relevant security patch. As a temporary mitigation, perform a thorough code review to identify and refactor any instances where dictionary expansion is used to pass arguments to `QuerySet.filter()`, `QuerySet.exclude()`, or `QuerySet.get()`, particularly for the internal `_connector` argument, as this is an insecure and non-standard coding practice.

How to confirm the fix worked

To validate the fix, confirm that the installed Django version is patched by running `python -m django --version` or `pip freeze | grep Django` in the application's environment and ensuring the version is 5.1.14+, 4.2.26+, or 5.2.8+. To check for exposure, use static analysis (SAST) or manual code review to search for the vulnerable pattern: `QuerySet.filter(**kwargs)`, `QuerySet.exclude(**kwargs)`, or `QuerySet.get(**kwargs)` where `kwargs` could contain a user-controlled `_connector` key.

Typical attack path

1. An attacker identifies a target application running a vulnerable version of Django.
2. The attacker probes application endpoints to find one where user input is used to construct a dictionary for a database query.
3. A malicious dictionary containing SQL injection payloads is crafted and submitted via an HTTP request.
4. The application code insecurely uses dictionary expansion to pass the malicious dictionary to the `_connector` argument of a `QuerySet` method.
5. The Django ORM generates and executes a malicious SQL query against the database.
6. The attacker gains unauthorized access to read, modify, or delete data in the database.

How to detect it

To detect potential exploitation, security teams should focus on database query logs. Enable detailed logging on your database server and search for malformed or suspicious SQL queries that do not align with expected application behavior. Look for queries containing injected logic such as `OR '1'='1'`, `UNION SELECT`, or database-specific reconnaissance functions like `pg_sleep()` or `version()`. Additionally, review web server access logs for unusual POST requests containing dictionary-like structures or SQL keywords, and monitor application logs for unexpected errors originating from the database layer.

What your security team should do

• Immediately identify all applications using the Django framework and their versions. Prioritize patching systems running versions 5.1 before 5.1.14, 4.2 before 4.2.26, and 5.2 before 5.2.8.
• Deploy the required patches to all affected systems as a top priority, given the critical CVSS score and the availability of public exploit code.
• If patching is delayed, implement enhanced monitoring of database query logs for anomalous SQL syntax and consider using a Web Application Firewall (WAF) with strict SQLi rules as a compensating control.
• Initiate a code review process to find and eliminate the insecure practice of passing user-controlled dictionaries via expansion to ORM methods.