CVE-2025-64459: 
Django vulnerability analysis and mitigation

CVE-2025-64459 is a critical SQL injection vulnerability in the Django web framework affecting the ORM's QuerySet.filter(), QuerySet.exclude(), QuerySet.get() methods and the Q() class. The flaw is triggered when a specially crafted dictionary is passed with dictionary expansion (**kwargs) as the _connector argument, allowing unsanitized SQL to be injected into database queries. It affects Django 4.2 before 4.2.26, 5.1 before 5.1.14, and 5.2 before 5.2.8; earlier unsupported series (3.2.x, 4.1.x, 5.0.x) were not formally evaluated but may also be affected. The vulnerability was reported by researcher cyberstan and disclosed on November 5, 2025. It carries a CVSS v3.1 base score of 9.1 (Critical) (GitHub Advisory, Django Blog).

The root cause is improper neutralization of special elements in SQL commands (CWE-89). Django's ORM methods (filter(), exclude(), get()) and the Q() class accept a _connector keyword argument that specifies how query conditions are joined (e.g., AND, OR). When a user-controlled dictionary is expanded into these methods using Python's ** operator, the _connector value is not properly sanitized before being incorporated into the generated SQL query, allowing an attacker to inject arbitrary SQL. Exploitation requires no authentication and no user interaction — the attacker only needs network access to an application endpoint that passes user-controlled data via dictionary expansion to one of the vulnerable ORM methods. A technical write-up and proof-of-concept are publicly available (PoC Write-up, GitHub Advisory).

Successful exploitation allows a remote, unauthenticated attacker to execute arbitrary SQL commands against the backend database, resulting in high confidentiality and integrity impact. Attackers can exfiltrate sensitive data (user credentials, PII, application secrets), modify or delete database records, and potentially escalate privileges within the application. Depending on database configuration and permissions, exploitation could enable lateral movement to other systems or command execution via database features (e.g., xp_cmdshell on MSSQL or COPY TO/FROM on PostgreSQL) (GitHub Advisory, Endor Labs).

A public proof-of-concept exploit and technical write-up were published on November 7, 2025, shortly after disclosure (PoC Write-up). Multiple additional PoC repositories have since appeared on GitHub (e.g., nunpa/CVE-2025-64459, stanly363/CVE-2025-64459-Poc, B1ack4sh/Blackash-CVE-2025-64459, ALPYAHYA/CVE-2025-64459-Exploit-Fix), and a TryHackMe lab was created for hands-on practice. The EPSS score is approximately 0.014–0.296% (varying by source), indicating moderate predicted exploitation probability. As of available data, there is no confirmed evidence of in-the-wild exploitation or CISA KEV catalog listing, and no specific threat actor attribution has been made (GitHub Advisory, Feedly).

1. Reconnaissance: Identify Django-based web applications using tools like Wappalyzer, HTTP response headers (X-Powered-By, csrfmiddlewaretoken cookies), or Shodan/Censys. Determine the Django version if possible via error pages or version disclosure.
2. Identify vulnerable code patterns: Look for application endpoints that accept user-supplied dictionary data and pass it with ** expansion to QuerySet.filter(), QuerySet.exclude(), QuerySet.get(), or Q() — for example, MyModel.objects.filter(**user_data) where user_data is attacker-controlled.
3. Craft malicious payload: Construct a dictionary where the _connector key contains a SQL injection payload. For example: {'_connector': 'AND 1=1 UNION SELECT username,password FROM auth_user--'}. This value bypasses Django's ORM parameterization because _connector is used to build the SQL structure rather than as a parameterized value.
4. Submit the payload: Send an HTTP request to the vulnerable endpoint with the crafted dictionary, either as JSON body, query parameters, or form data, depending on how the application processes input.
5. Extract data: Observe the application's response for injected query results. Use blind SQL injection techniques (time-based or boolean-based) if the application does not return query results directly.
6. Escalate: Leverage extracted credentials or session tokens to authenticate as privileged users, or use database-specific features to attempt OS-level command execution if database permissions allow (PoC Write-up, GitHub Advisory).

• Network: Unusual or malformed HTTP requests to application endpoints containing _connector keys in JSON/form payloads with SQL syntax (e.g., UNION SELECT, AND 1=, OR 1=1, comment sequences -- or /**/); unexpected outbound database connections or data exfiltration traffic.
• Logs: Django application logs or web server access logs showing requests with anomalous parameter values containing SQL keywords; database query logs recording unexpected UNION, SELECT, or multi-statement queries originating from the Django application user; error logs showing SQL syntax errors from malformed injection attempts.
• Database: Unexpected queries in the database slow query log or audit log that include UNION SELECT or reference system tables (e.g., information_schema, pg_tables, sqlite_master); new or modified database users or permissions.
• File System: Unexpected files written to the server if the attacker leveraged database file-write capabilities (e.g., SELECT INTO OUTFILE on MySQL); new web shell files in the Django application directory.
• Process: Unusual child processes spawned by the Django/Python process (e.g., bash, sh, curl, wget) if OS command execution was achieved via database features.

Django has released patched versions addressing this vulnerability: 4.2.26, 5.1.14, and 5.2.8. All users of affected versions should upgrade immediately. As a workaround where immediate upgrade is not possible, developers should audit all code paths that pass user-controlled data via dictionary expansion (**kwargs) to QuerySet.filter(), QuerySet.exclude(), QuerySet.get(), or Q(), and ensure the _connector argument is never derived from user input. Additionally, implementing input validation, using allowlists for accepted query parameters, and applying least-privilege database permissions can reduce the blast radius of exploitation. Oracle Solaris 11.4 users should apply the relevant SRU patches, and Red Hat Ansible Automation Platform users should apply RHSA-2025:23069 and RHSA-2025:23196 (Django Blog, GitHub Advisory, Oracle Advisory).

The Django Software Foundation published a security advisory and blog post on November 5, 2025, crediting researcher cyberstan for responsible disclosure (Django Blog). The vulnerability received significant community attention, trending on Reddit's CVEWatch for multiple days (November 7–13, 2025) and generating discussion on Mastodon, Bluesky, and LinkedIn among security practitioners. Security outlets including SecurityOnline, GBHackers, CyberSecurityNews, eSecurity Planet, and The Hacker News covered the vulnerability in weekly recaps. Belgium's Centre for Cybersecurity (CCB) issued a warning urging immediate patching, characterizing it as a critical unauthenticated SQL injection flaw. Emerging Threats released detection rules (ruleset v11058) within two days of disclosure, and Cloudflare WAF rules were updated in February 2026 to detect exploitation attempts.