Django Vulnerabilities Expose Apps to SQL Injection and DoS Attacks
November 13, 2025
ChatGPT 
The Django Software Foundation has rolled out important security fixes addressing two serious vulnerabilities that could let attackers manipulate databases and disrupt application availability.
The vulnerabilities such as CVE-2025-64459 (SQL Injection) and CVE-2025-64458 (Denial of Service), were found in commonly used functions of the Django web framework.
These vulnerabilities affect how Django processes queries and handles redirects, especially when user-supplied input is not properly validated.
Both vulnerabilities pose significant risks: the SQL bug threatens data integrity, while the DoS flaw impacts application availability.
SQL Injection Vulnerability (CVE-2025-64459)
Risk Analysis
Severity: CRITICAL
CVSSv3.1: Base Score: 9.1 CRITICAL
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Exploit available in public: No
Exploit complexity: Low
The first and more critical vulnerabilitiy lies in Django’s query construction methods such as filter(), exclude(), get(), and Q() objects.
When developers pass dictionary-based arguments (like using **kwargs) that include unvalidated user input, attackers can inject malicious SQL code into backend queries.
This manipulation can give them direct access to application databases, allowing them to view, modify, or delete sensitive data.
Most people think “ORM = safe from SQL injection.” That is generally true for values: Django’s ORM parameterizes inputs so values cannot turn into SQL. This vulnerability is different: it lets an attacker influence the structure of the query, the pieces the ORM combines to build SQL rather than only the parameter values.
Concretely, when a developer takes a dictionary of user-supplied filters and expands it directly into filter() / exclude() / get() or into a Q() object (using ** expansion), a specially crafted input can include keywords that the ORM mistakenly treats as structural directives (for example _connector), and that can change how conditions are combined. That structural control can lead to queries that return or change data the application never intended to expose.
Why that is worse than normal injection: parameterization protects values (it prevents ‘ OR ‘1’=’1 style attacks), but it cannot protect the grammar of the query. If an attacker controls whether clauses are joined with AND or OR, or can inject alias/connector-like pieces, they can force the ORM to create dangerous SQL shapes. Because many apps build dynamic filters from web parameters, the attack surface is large and exploitation complexity is low. Security vendors and advisories treat this as high criticality.
Denial-of-Service (DoS) Vulnerability (CVE-2025-64458)
Risk Analysis
Severity: CRITICAL
CVSSv3.1: Base Score: 7.5 HIGH
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Exploit available in public: No
Exploit complexity: Low
The second vulnerability targets Django deployments on Windows systems.
It stems from how Django uses Python’s NFKC Unicode normalization in the HttpResponseRedirect and HttpResponsePermanentRedirect functions.
By sending specially crafted Unicode input, attackers can trigger excessive CPU and memory consumption, slowing down or even halting the application.
This does not compromise data but can make the web service unavailable to legitimate users, a common symptom of DoS attacks.
How Attackers Might Exploit these Vulnerabilities
For the SQL vulnerabilities, the attacker’s simplest path is to call endpoints that accept dynamic filter parameters (search, lists, reporting APIs) and try to inject keys/values that manipulate connectors or other internal arguments. Because the vulnerability can be triggered by dictionary expansion of request data, any endpoint that blindly forwards query parameters into filter(**…) or Q(**…) is risky. If successful, attackers could enumerate tables, extract rows, or even perform writes depending on database privileges.
For the Windows DoS, the attacker targets views that perform redirects (login flows, OAuth callbacks, SSO endpoints, or any view that accepts user-provided URLs) and simply sends requests containing very long or complex Unicode payloads. A low bandwidth attacker can cause high CPU usage on Windows hosts; at scale this becomes a denial-of-service.
How to Protect Your Django Applications
To mitigate both vulnerabilities:
- Update to Django 5.2.8, 5.1.14, or 4.2.26. – These releases contain patches that block SQL injection attempts and fix the Unicode handling vulnerabilities.
- Validate User Input – Avoid directly using user-supplied data in query filters. Always sanitize and validate before including them in filter() or Q() objects.
- Use a Web Application Firewall (WAF) – Deploying a WAF such as AppTrana WAAP can help automatically detect and block SQL injection attempts and DoS payloads before they reach your application.
- Monitor and Test Regularly – Run periodic vulnerability scans and review logs for any unusual database queries or traffic spikes.
AppTrana WAAP Coverage for Django SQL Injection & DoS (CVE-2025-64459, CVE-2025-64458)
AppTrana WAAP provides comprehensive, out-of-the-box protection against both CVE-2025-64459 and CVE-2025-64458. Its AI-driven, fully managed WAF detects and blocks SQL Injection attempts exploiting unsafe query construction in Django applications, preventing unauthorized database access or data tampering.
At the same time, it safeguards Windows-based deployments from Denial-of-Service (DoS) attacks by identifying and throttling abnormal traffic patterns or malicious Unicode payloads that can overload system resources.
Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.
