CVE-2022-34265: Django Trunc/Extract SQL Injection Flaw

CVE-2022-34265 Overview

CVE-2022-34265 is a critical SQL Injection vulnerability affecting Django web framework versions 3.2 before 3.2.14 and 4.0 before 4.0.6. The vulnerability exists in the Trunc() and Extract() database functions, which are susceptible to SQL injection when untrusted data is used as a kind or lookup_name value. Applications that constrain the lookup name and kind choice to a known safe list are unaffected by this vulnerability.

Critical Impact

Remote attackers can exploit this SQL Injection vulnerability to execute arbitrary SQL commands against the database, potentially leading to unauthorized data access, data modification, or complete database compromise without requiring authentication.

Affected Products

• Django 3.2 before 3.2.14
• Django 4.0 before 4.0.6
• Djangoproject Django (all affected versions)

Discovery Timeline

• July 4, 2022 - CVE-2022-34265 published to NVD
• July 4, 2022 - Django Project releases security patches
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2022-34265

Vulnerability Analysis

This SQL Injection vulnerability (CWE-89) resides in Django's ORM (Object-Relational Mapping) layer, specifically within the Trunc() and Extract() database functions. These functions are commonly used for date/time manipulation in Django queries, allowing developers to truncate or extract specific components from datetime fields.

The core issue stems from insufficient input validation when processing the kind parameter in Trunc() and the lookup_name parameter in Extract(). When these parameters accept user-controlled input without proper sanitization or validation against a safe allowlist, malicious SQL code can be injected directly into the generated database query.

An attacker exploiting this vulnerability can achieve full database compromise, including reading sensitive data from other tables, modifying or deleting records, and potentially executing administrative operations on the database server depending on the database configuration and privileges.

Root Cause

The root cause of CVE-2022-34265 is improper input validation in Django's database function handling. The Trunc() and Extract() functions directly interpolate the kind and lookup_name parameters into SQL queries without adequately sanitizing or validating them against an expected set of safe values. This allows attackers to break out of the intended SQL context and inject arbitrary SQL statements when user-controlled data flows into these parameters.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by submitting crafted input through any application endpoint that passes user-controlled data to the Trunc() or Extract() database functions without proper validation.

For example, if an application allows users to specify date truncation preferences (such as "year", "month", "day") and passes this input directly to Trunc(), an attacker can inject SQL code instead of a legitimate truncation value. The injected SQL executes with the privileges of the database user configured for the Django application.

The vulnerability mechanism involves passing malicious input as the kind or lookup_name parameter to these database functions. When Django constructs the SQL query, the unsanitized parameter is embedded directly into the query string, allowing SQL injection. Detailed technical information is available in the Django Security Release Notes and the Django Weblog Security Releases.

Detection Methods for CVE-2022-34265

Indicators of Compromise

• Unusual SQL error messages in application logs containing unexpected date/time function syntax
• Database query logs showing malformed DATE_TRUNC, EXTRACT, or equivalent date manipulation functions with suspicious payloads
• Evidence of data exfiltration, unauthorized database queries, or unexpected data modifications
• Web application firewall or intrusion detection alerts for SQL injection patterns in request parameters

Detection Strategies

• Monitor application logs for SQL syntax errors related to date/time functions that may indicate injection attempts
• Deploy web application firewalls (WAF) with SQL injection detection rules focused on date manipulation function patterns
• Implement database activity monitoring to detect anomalous queries involving Trunc() or Extract() operations
• Conduct code review to identify instances where user input flows to the kind or lookup_name parameters without validation

Monitoring Recommendations

• Enable detailed logging for Django database queries in non-production environments to identify vulnerable code paths
• Configure database audit logging to capture all queries executed against sensitive tables
• Set up alerting for repeated SQL syntax errors that may indicate active exploitation attempts
• Monitor for unexpected database connections or privilege escalation activities

How to Mitigate CVE-2022-34265

Immediate Actions Required

• Upgrade Django to version 3.2.14 or later for the 3.2.x branch
• Upgrade Django to version 4.0.6 or later for the 4.0.x branch
• Audit all application code for uses of Trunc() and Extract() functions that accept user input
• Implement strict allowlist validation for kind and lookup_name parameters before passing to database functions

Patch Information

Django has released security patches addressing this vulnerability. The fixes are included in Django versions 3.2.14 and 4.0.6. Organizations should upgrade to these versions or later immediately. Detailed patch information and release notes are available from the Django Security Release Notes and the official Django Weblog Security Releases.

Additional advisories have been published by downstream distributors including Debian Security Advisory DSA-5254, Fedora Package Announcements, and NetApp Security Advisory.

Workarounds

• Constrain the kind and lookup_name parameters to a predefined allowlist of safe values (e.g., year, month, day, hour, minute, second)
• Validate all user input against expected patterns before passing to database functions
• Implement input sanitization as a defense-in-depth measure even if using an allowlist
• Consider using parameterized values only from application code rather than accepting user-specified date truncation options

# Example allowlist validation for Trunc() kind parameter
SAFE_TRUNC_KINDS = {'year', 'quarter', 'month', 'week', 'day', 'hour', 'minute', 'second'}

def safe_trunc(queryset, field_name, kind):
    if kind not in SAFE_TRUNC_KINDS:
        raise ValueError(f"Invalid truncation kind: {kind}")
    return queryset.annotate(truncated=Trunc(field_name, kind))