CVE-2026-1312

What it actually does

This is a Django ORM SQL injection flaw in QuerySet.order_by() when column aliases containing periods are reused through a crafted dictionary expansion with FilteredRelation. If an application constructs FilteredRelation/order_by inputs from attacker-influenced data, Django can generate unsafe SQL instead of correctly treating the alias as data/identifier syntax. Successful exploitation can allow an authenticated or otherwise application-authorized attacker to alter the generated SQL query, potentially reading unauthorized query results or modifying query logic. The assessed impact is limited confidentiality and integrity impact, with no direct availability impact, and exploitation depends on a vulnerable application code pattern being reachable.

Why it matters to the business

Applications using affected Django versions may expose database data or query behavior to users who should not have that access if the vulnerable ORM pattern is present in reachable application functionality. The risk is moderate rather than broadly wormable: the issue is not in every Django application by default, requires a specific FilteredRelation/order_by usage pattern, and currently has low EPSS, no known KEV listing, and no reported exploit maturity. However, Django is widely used, the issue has been public for 188 days, and unsupported Django branches were not fully evaluated, so organizations should prioritize remediation where internet-facing or multi-user applications accept filtering, sorting, reporting, search, analytics, or API parameters that influence ORM query construction.

How an attack unfolds

An attacker first identifies an application endpoint that allows user-controlled filtering, searching, sorting, reporting, or API query parameters backed by Django ORM queries. The vulnerable code path must combine FilteredRelation with dictionary expansion and then reuse a column alias containing a period in QuerySet.order_by(). The attacker authenticates or otherwise reaches the affected function, supplies crafted input that becomes part of the alias/filter/sort dictionary, and causes Django to build malformed or attacker-influenced SQL. The database then executes the generated query, which may change ordering, filtering, joins, or selected data in a way the application did not intend. Practical impact depends heavily on the application’s query shape, database permissions, error handling, and whether responses or timing differences reveal the injected behavior.

How to fix it

Upgrade Django to a fixed release: Django 6.0.2 or later for the 6.0 series, Django 5.2.11 or later for the 5.2 series, and Django 4.2.28 or later for the 4.2 LTS series. For source-based deployments, include the upstream fix commit ba00558ddac694d92b05d12ecd2a5b7fcc1de025 or a later commit containing the fix. Unsupported Django branches such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and should be migrated to a supported fixed branch rather than assumed safe. For affected MinimOS packages, upgrade grafana-12.0 and grafana-12.0-oci-compat to 12.0.7-r0 or later. As defense in depth, review code for FilteredRelation combined with dynamic dictionary expansion, dynamic aliases, and user-controlled order_by values; replace user-controlled field names with strict allowlists; reject aliases containing unexpected punctuation; and ensure database accounts used by applications have least-privilege permissions.

How to confirm the fix worked

Confirm runtime package versions with dependency inventory, SBOM tooling, pip freeze, import django; django.get_version(), container image package metadata, or application startup logs. Verify Django is at 6.0.2+, 5.2.11+, or 4.2.28+, or that the source tree includes commit ba00558ddac694d92b05d12ecd2a5b7fcc1de025 or later. For MinimOS-based images, verify grafana-12.0 and grafana-12.0-oci-compat are 12.0.7-r0 or later. Perform code review or static search for FilteredRelation, order_by, annotate aliases containing periods, and dictionary expansion using attacker-influenced values. Run regression tests for application sorting/filtering/reporting endpoints after upgrade. Where safe in a non-production environment, exercise endpoints with unusual sort/filter parameter names containing periods and confirm they are rejected or handled without SQL syntax errors or unexpected query behavior.

Typical attack path

1. Discover a Django-powered endpoint that accepts user-controlled filter, sort, search, report, or API query parameters.
2. Determine that the endpoint reaches ORM logic using FilteredRelation together with QuerySet.order_by().
3. Supply crafted parameter names or values intended to influence a dictionary-expanded alias, especially alias-like input containing periods.
4. Trigger the application to generate SQL using the unsafe alias/order_by combination.
5. Observe application responses, database errors, timing differences, or returned records to confirm query manipulation.
6. Use the manipulated query behavior to infer, expose, or alter data returned by the application within the limits of the database user and application logic.

How to detect it

To determine whether exploitation may already have occurred, review application access logs, Django error logs, web/API gateway logs, database error logs, and database statement/audit logs for endpoints that accept sort, filter, search, report, or ordering parameters. Focus on requests containing unusual parameter names or values with periods, SQL metacharacters, encoded punctuation, repeated alias-like fields, or unexpected ordering fields. Correlate these requests with Django exceptions such as django.db.utils.ProgrammingError or OperationalError, database syntax errors near ORDER BY, JOIN, WHERE, or alias references, and anomalous increases in 400/500 responses. If database statement logging is available, inspect generated SQL around suspicious requests for unexpected alias names containing periods or query structure that differs from normal application behavior. Also review successful responses following probing errors, as attackers may first trigger SQL errors and then refine payloads to avoid visible failures. No named threat actors, KEV activity, or ransomware campaigns are currently associated with this issue in the provided intelligence.

• FilteredRelation
• order_by
• django.db.utils.ProgrammingError
• django.db.utils.OperationalError
• syntax error at or near "ORDER"
• syntax error at or near "WHERE"
• syntax error at or near "JOIN"
• column alias contains a period
• ORDER BY
• %2E
• sort=
• ordering=
• order_by=
• filter=

What your security team should do

• Inventory Django applications and container images, prioritizing internet-facing, multi-tenant, reporting, admin, analytics, API, and search/filter-heavy services.
• Patch supported Django branches to 6.0.2+, 5.2.11+, or 4.2.28+; migrate unsupported Django versions to a supported fixed release.
• Upgrade affected MinimOS grafana-12.0 and grafana-12.0-oci-compat packages to 12.0.7-r0 or later where present.
• Search application code for FilteredRelation combined with dynamic dictionary expansion and QuerySet.order_by(), and treat user-controlled aliases or sort fields as high-risk.
• Enforce allowlists for client-selectable sort/filter fields instead of passing raw request parameters into ORM aliases, annotations, or order_by calls.
• Enable or review database statement/error logging for affected applications during the exposure window, especially around endpoints that support dynamic filtering and ordering.
• Look for historical application exceptions and database errors indicating malformed SQL generated from sort/filter parameters.
• Because there is no KEV listing, no known ransomware use, low EPSS, and no public exploit maturity reported, prioritize based on exposure and vulnerable code presence rather than emergency blanket disruption.