CVE-2025-57833

What it actually does

Django's ORM incorrectly handled column alias names when FilteredRelation was used with QuerySet.annotate() or QuerySet.alias() and aliases were supplied through dictionary expansion as **kwargs. If an application allowed untrusted input to influence the keys of that dictionary, an attacker could craft an alias that was incorporated into generated SQL unsafely, resulting in SQL injection. Impact depends on the database backend, database permissions, and application query path, but may include unauthorized data reads, query manipulation, authentication or authorization bypass through altered query logic, and in high-privilege database configurations, broader database compromise.

Why it matters to the business

Applications using affected Django versions may expose sensitive business data if they pass user-controlled field, alias, filter, reporting, or search parameters into vulnerable ORM patterns. Although this is not listed in CISA KEV, has no reported ransomware association, and exploit maturity is currently listed as none, the EPSS value indicates non-trivial exploitation interest, and Django's wide use makes vulnerable patterns important to identify across application portfolios. Successful exploitation could cause data disclosure, regulatory exposure, loss of customer trust, and operational disruption from incident response or emergency patching.

How an attack unfolds

An attacker first identifies a Django application endpoint that accepts dynamic query-building input, such as report fields, filters, annotations, joins, search facets, or API parameters that are later expanded into QuerySet.annotate() or QuerySet.alias(). The vulnerable condition requires the application to use FilteredRelation and to pass a dictionary into these ORM methods using **kwargs where the dictionary keys can be influenced by the attacker. The attacker submits a crafted alias name containing SQL syntax intended to break out of the expected column-alias context. Django then generates SQL containing the unsafe alias, and the database executes a modified query. Depending on the surrounding query and database permissions, the attacker may extract unauthorized data, alter query conditions, trigger database errors for blind inference, or use timing/error behavior to confirm exploitability.

How to fix it

Upgrade Django to a fixed release: Django 4.2.24 or later for the 4.2 LTS branch, Django 5.1.12 or later for the 5.1 branch, and Django 5.2.6 or later for the 5.2 branch. Source builds should include commit f71d9c35e4c28614b4c079462f135637a59bfe19 or a later upstream commit containing the fix. Rebuild and redeploy all application images, virtual environments, and dependency lockfiles that package affected Django versions. As a defense-in-depth measure, audit application code for QuerySet.annotate(**...), QuerySet.alias(**...), and FilteredRelation usage where dictionary keys can originate from HTTP parameters, JSON request bodies, GraphQL arguments, form fields, saved user preferences, or other untrusted data. Do not allow arbitrary client-supplied alias names; map user choices to a fixed server-side allowlist of known-safe alias identifiers. Ensure database accounts used by applications have least-privilege access and cannot perform unnecessary administrative actions.

How to confirm the fix worked

Confirm the deployed Django version with package inventory tooling, dependency lockfiles, container manifests, or runtime checks such as python -m django --version, pip show Django, pip freeze, poetry show django, or equivalent package manager output. Verify all running application instances use Django 4.2.24, 5.1.12, 5.2.6, or a later fixed version. Perform code review or static search for FilteredRelation combined with annotate(**dict_variable) or alias(**dict_variable), especially where dict keys are derived from request data. Add regression tests that attempt to use unexpected alias names containing SQL metacharacters and confirm they are rejected or safely handled. Review generated SQL in tests for affected query paths to ensure aliases are quoted or validated correctly. Confirm that redeployed containers, serverless packages, and background workers were rebuilt after dependency updates rather than only updating source repositories.

Typical attack path

1. Reconnaissance identifies a Django-based application endpoint that supports dynamic filtering, reporting, field selection, relationship filtering, or annotation-style query behavior.
2. The attacker probes inputs that appear to control returned fields, aliases, annotations, joins, or related-object filters.
3. The attacker looks for database error messages, timing differences, or response-shape changes that indicate user input is reaching ORM-generated SQL.
4. The attacker submits a crafted alias through an input path that is expanded as **kwargs into QuerySet.annotate() or QuerySet.alias() while FilteredRelation is in use.
5. The vulnerable Django version emits SQL with an attacker-controlled column alias in an unsafe context.
6. The database executes the manipulated SQL, allowing data exposure or query manipulation within the privileges of the application's database account.
7. The attacker iterates payloads to enumerate schema details, extract sensitive records, or bypass application-level query restrictions.

How to detect it

To determine whether exploitation already occurred, focus on applications that used affected Django versions and contained FilteredRelation together with QuerySet.annotate() or QuerySet.alias() using **kwargs from dynamic dictionaries. Review HTTP access logs, API gateway logs, WAF logs, and application request logs for parameters or JSON fields related to aliases, annotations, filters, fields, reports, joins, or related-object queries that contain SQL metacharacters, comments, Boolean logic, UNION-style syntax, database function calls, or unusual quoting. Review Django application logs for database exceptions occurring after requests to dynamic query endpoints, especially syntax errors, invalid column references, unterminated quoted identifiers, or ProgrammingError/OperationalError traces. Review database logs for malformed SELECT statements, unexpected UNION clauses, tautological WHERE conditions, time-delay functions, or repeated syntax errors from the application database user. Correlate suspicious requests with response status codes, error spikes, unusual response sizes, and database query timing anomalies. Because this flaw is application-pattern dependent, absence of a generic signature does not prove safety; combine log review with code review and version validation.

• FilteredRelation
• QuerySet.annotate(
• QuerySet.alias(
• annotate(**
• alias(**
• django.db.utils.ProgrammingError
• django.db.utils.OperationalError
• syntax error at or near
• unterminated quoted identifier
• invalid column reference
• UNION SELECT
• ' OR '1'='1
• " OR "1"="1
• --
• /*
• */
• pg_sleep(
• SLEEP(
• WAITFOR DELAY
• information_schema
• sqlite_master

What your security team should do

• Inventory all Django applications and prioritize internet-facing systems, APIs, reporting interfaces, admin-like search features, and applications handling regulated or sensitive data.
• Patch to Django 4.2.24, 5.1.12, 5.2.6, or later, and verify the fixed version is present in production runtime artifacts.
• Search application code for FilteredRelation with QuerySet.annotate() or QuerySet.alias() using dictionary expansion and review whether alias keys can be influenced by users.
• Implement allowlists for dynamic field, annotation, filter, and alias names; never pass arbitrary request-controlled dictionary keys into ORM query-construction methods.
• Enable or increase retention for application error logs, database audit/query logs, and WAF/request logs for endpoints that perform dynamic querying.
• Review recent logs for suspicious SQL syntax in request parameters and for database syntax errors associated with dynamic reporting, filtering, or annotation endpoints.
• Validate database least privilege so successful SQL injection cannot escalate beyond the minimum data access required by the application.
• Track Django security advisories and ensure dependency scanning detects vulnerable Django versions in repositories, containers, and deployed artifacts.