External risk intelligence

Django SQL Injection via Column Aliases in QuerySet Methods

CVE advisorySeverity: CRITICAL (CVSS 9.8)

CVE-2025-59681

Django is a widely used web application framework typically employed to build public-facing web applications and APIs. Since the vulnerability exists in database query methods often triggered by user-supplied input through web requests, these applications are frequently reachable from the internet.

SQL Injection

Djangoproject Django

4.2 to before 4.2.255.1 to before 5.1.135.2 to before 5.2.7

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A security vulnerability has been identified in the Django web framework that could allow attackers to inject malicious SQL code into databases. This issue affects specific versions of Django and, if exploited, could lead to unauthorized access or manipulation of sensitive data stored in your applications' databases. The primary concern is to determine if your organization utilizes the affected versions and is potentially exposed.

SQL injection in Django database queries.
Could allow attackers to access or alter data.
Confirm relevance and assess potential exposure.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by sending specially crafted requests to a Django application that uses specific database query methods. This could lead to unauthorized access and modification of sensitive data within the application's database.

No authentication or user interaction needed.
Via specially crafted dictionary to query methods.
Allows unauthorized data access and modification.

Live Threat

Current exploitation, exposure, and threat context

On MySQL and MariaDB databases, this vulnerability could allow an attacker to execute arbitrary SQL commands by providing specially crafted input through certain Django query methods. This could affect the integrity and availability of the database, potentially leading to unauthorized access to or modification of data.

Database integrity and availability.
Via specially crafted dictionary expansion.
Arbitrary SQL command execution.

Operational Fix

Recommended remediation, mitigation, and detection steps

Application owners and platform teams are likely responsible for addressing this SQL injection vulnerability in Django. The first practical step involves identifying all instances of the affected Django versions, confirming their reachability and business criticality, and then locating the accountable owners to plan remediation based on risk.

Application owners should coordinate remediation.
Verify all affected Django instances.
Plan risk-based mitigation or patching.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Django and what is it used for?

Django is a high-level Python web framework designed for rapid development. It provides built-in tools for database management, authentication, and URL routing, making it a popular choice for building secure, scalable websites, complex data-driven applications, and robust APIs.

What does CWE-89 mean for CVE-2025-59681?

CWE-89 refers to SQL Injection. In the context of this CVE, it means the application fails to properly sanitize user-supplied input before using it in a database query. Specifically, when using certain QuerySet methods with dictionary expansion, an attacker can manipulate the structure of the SQL command, potentially allowing them to view or alter data they should not have access to.

How is this SQL injection triggered?

The vulnerability is triggered when a Django application uses QuerySet methods like annotate() or aggregate() with a specially crafted dictionary passed through keyword arguments. This flaw specifically impacts applications using MySQL or MariaDB. It is important to note that the issue relies on how these specific database engines process the resulting queries; it does not occur if the application uses a different database backend.

Is my Django application at risk?

If your application is internet-facing, it is at higher risk because attackers can send crafted requests to trigger the vulnerability without needing prior authentication. According to Halo Surface Signal, because Django is frequently used for public-facing web applications and the flaw is reachable through standard web requests, many instances are likely accessible from the internet, making this a relevant concern for most deployments.

How do I start addressing this vulnerability?

The first step is to perform an inventory of your environment to identify any services running the affected versions of Django. Once you have a list of all instances, prioritize those that are internet-facing or handle sensitive data. Coordinate with your application development teams to verify the use of the impacted QuerySet methods and plan your upgrade path to a secure version.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.