TL;DR

A critical SQL injection vulnerability (CVE-2025-64459) has been disclosed in Django, one of the most widely-used Python web frameworks, powering countless web applications—from small business sites to large-scale services.

Attackers can manipulate database query logic by injecting internal query parameters (_connector and _negated) when applications pass user-controlled input directly into filter(), exclude(), or get() calls.

This can lead to unauthorized data access, authentication bypass or privilege escalation. The high impact on confidentiality and integrity, the low attack complexity and the fact that vulnerable applications may be exploitable with no authentication required makes this a critical vulnerability with a CVSS v3.1 score of 9.1.

Affected Django versions include the supported versions 6.0 (currently at beta status), 5.2, 5.1 and 4.2, and potentially older, unsupported versions.

To fix, upgrade immediately to one of the patched versions:

• Django 5.2.8
• Django 5.1.14
• Django 4.2.26

Technical Analysis

Many Django applications accept query parameters via API requests to power dynamic filtering through Django's QuerySet methods (filter(), exclude(), get()). When used with dictionary expansion of user-controlled input, the vulnerability allows attackers to inject internal Django parameters that control SQL query logic.

Django uses _connector (AND/OR/XOR) and _negated (boolean inversion) as internal parameters for query construction. Before the patch, these parameters were not validated when supplied through user input, allowing attackers to manipulate query behavior.

How the attack works 

Below is an example of a common vulnerable code pattern alongside what an exploitable version looks like so you can see how the attack is working and compromising your database.

Vulnerable Code Pattern

Exploitation Example

‍Impact: Attacker gains access to the admin account and all user data.

Example Attack Scenarios

Let’s take a look at some example scenarios showing the potential impacts when this critical vulnerability is being exploited. 

Scenario 1: Authentication Bypass

Application accepts login credentials via dictionary expansion. Attacker adds _connector=OR&is_superuser=True to gain admin access without valid credentials.

Scenario 2: Data Exfiltration

Document access API filters by owner. Attacker adds _connector=OR&confidential=True to access all confidential documents regardless of ownership.

Scenario 3: Privilege Escalation

Permission checks use dictionary expansion. Attacker adds _negated=True to invert access control logic and gain unauthorized access.

The Fix

Django implemented two-layer validation to address this vulnerability:

Layer 1 - QuerySet Validation

File: django/db/models/query.py

Layer 2 - Q Object Validation

File: django/db/models/query_utils.py

Mitigation 

We’ve put together some quick and immediate mitigation pointers to help you navigate this vulnerability and ensure your applications aren’t exposed and become open to exploitation. It is important to take these steps especially if you are in the following categories.

Those with the following should act as a critical priority:

• Applications using dictionary expansion with user input in QuerySet methods
• REST APIs with dynamic filtering capabilities
• Search and reporting interfaces
• Authentication and authorization systems

However, all Diago applications should:

1. Upgrade immediately
2. Review code for vulnerable patterns
3. Implement secure coding practices
4. Add security tests

Immediate Actions

• Upgrade to patched Django versions (5.2.8, 5.1.14, or 4.2.26)
• Deploy updates to all production environments immediately
• Review logs for exploitation attempts (_connector, _negated in requests)

Code Security Best Practices

• Never pass request.GET.dict() or request.POST.dict() directly to QuerySet methods
• Use Django Forms to validate all user input
• Implement parameter whitelisting for filter endpoints
• Use explicit field mapping instead of dictionary expansion

Detection

• Search logs for suspicious parameters: grep -i "_connector" /var/log/nginx/access.log
• Review recent authentication events and data access patterns
• Check for unusual admin access or privilege escalations

Testing and Automated Security

• Add tests to verify _connector and _negated parameters are rejected
• Audit codebase for vulnerable patterns: grep -r "\.filter(\*\*" --include="*.py" .
• Test all endpoints accepting user-controlled filters
• Use security scanning tools like EndorLabs to automatically detect vulnerable patterns
• Implement continuous security monitoring in your CI/CD pipeline

References

• Official advisory from Django

Official fix commits

• Main Branch: 98e642c691
• Django 6.0.x: 06dd38324a
• Django 5.2.x: 6703f364d7
• Django 5.1.x: 72d2c87431
• Django 4.2.x: 59ae82e670

Related Django vulnerabilities

• CVE-2025-59681: SQL injection in .extra() (October 2025)
• CVE-2024-42005: SQL injection in .values()/.values_list() (August 2024)
• CVE-2022-28346: SQL injection in .annotate()/.extra() (April 2022)

Conclusion

CVE-2025-64459 is a critical vulnerability and affects a very common Django development pattern. If you accept user-controlled filter parameters, your application may already be at risk. Immediate patching is essential. Organizations should prioritize upgrading Django, auditing code for vulnerable patterns, and implementing secure input validation practices.

‍