CVE-2024-53908: Django HasKey Lookup SQLi Vulnerability

CVE-2024-53908 Overview

CVE-2024-53908 is a SQL injection vulnerability discovered in the Django web framework affecting versions 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. The vulnerability exists in the direct usage of the django.db.models.fields.json.HasKey lookup when an Oracle database backend is used. If untrusted data is passed as the left-hand side (lhs) value, attackers can inject malicious SQL code, potentially leading to unauthorized data access, modification, or deletion.

Critical Impact

This SQL injection vulnerability allows unauthenticated remote attackers to execute arbitrary SQL commands against Oracle databases running Django applications, potentially compromising data confidentiality, integrity, and availability.

Affected Products

• Django 5.1 before 5.1.4
• Django 5.0 before 5.0.10
• Django 4.2 before 4.2.17

Discovery Timeline

• 2024-12-06 - CVE CVE-2024-53908 published to NVD
• 2025-06-09 - Last updated in NVD database

Technical Details for CVE-2024-53908

Vulnerability Analysis

This vulnerability is classified as CWE-89 (SQL Injection) and affects Django applications that directly use the HasKey lookup from django.db.models.fields.json module with Oracle database backends. The core issue lies in improper input validation when processing the left-hand side (lhs) parameter of the HasKey lookup.

When developers directly invoke the HasKey lookup with user-controlled input as the lhs value, the Oracle-specific implementation fails to properly sanitize or parameterize this input before constructing the SQL query. This allows attackers to craft malicious input that breaks out of the intended SQL context and executes arbitrary SQL commands.

It's important to note that applications using the standard jsonfield.has_key lookup via the double-underscore (__) syntax are not affected by this vulnerability, as Django properly handles input sanitization in that code path.

Root Cause

The root cause of this vulnerability stems from insufficient input sanitization in the Oracle database backend implementation of the HasKey lookup class. While other database backends may properly escape or parameterize the lhs value, the Oracle-specific code path did not adequately protect against SQL injection when untrusted data was directly passed to the lookup.

Attack Vector

The attack can be executed remotely over the network without authentication or user interaction. An attacker targeting a vulnerable Django application must:

1. Identify an endpoint or functionality that passes user-controlled input directly to the HasKey lookup
2. Craft a malicious payload that exploits the lack of input sanitization in the Oracle backend
3. Submit the payload through the vulnerable application endpoint
4. The malicious SQL is executed against the Oracle database with the privileges of the database user configured for the Django application

The vulnerability enables attackers to potentially read sensitive data from the database, modify or delete existing records, execute administrative operations, or in some cases, interact with the underlying operating system depending on database permissions and configuration.

Detection Methods for CVE-2024-53908

Indicators of Compromise

• Unusual SQL query patterns in Oracle database logs containing unexpected HasKey operations
• Application error logs showing malformed JSON field queries or Oracle syntax errors
• Database audit logs revealing unauthorized data access or modification operations
• Unexpected database queries executing outside normal application behavior patterns

Detection Strategies

• Monitor web application firewall (WAF) logs for SQL injection patterns targeting JSON field operations
• Implement database activity monitoring to detect anomalous query structures involving JSON operations
• Review application logs for errors related to django.db.models.fields.json.HasKey lookups
• Deploy intrusion detection rules targeting SQL injection payloads in HTTP parameters

Monitoring Recommendations

• Enable detailed Oracle database auditing for all JSON-related operations
• Configure alerting for failed or suspicious SQL queries originating from the Django application
• Monitor for unusual data exfiltration patterns from the database
• Track application performance anomalies that may indicate exploitation attempts

How to Mitigate CVE-2024-53908

Immediate Actions Required

• Upgrade Django to patched versions: 5.1.4, 5.0.10, or 4.2.17 or later
• Audit application code for direct usage of django.db.models.fields.json.HasKey with user-controlled input
• Implement input validation and sanitization for any data passed to JSON field lookups
• Consider switching to the standard jsonfield.has_key lookup via __ syntax which is not affected

Patch Information

The Django project has released security patches addressing this vulnerability. Administrators should upgrade to the following versions immediately:

• Django 5.1.x: Upgrade to version 5.1.4 or later
• Django 5.0.x: Upgrade to version 5.0.10 or later
• Django 4.2.x: Upgrade to version 4.2.17 or later

For detailed patch information, refer to the Django Security Release Notes and the Django Announcements Group.

Workarounds

• Avoid direct usage of django.db.models.fields.json.HasKey lookup with untrusted data until patching is complete
• Use the standard Django ORM syntax with double-underscore (__) for has_key lookups which is unaffected
• Implement strict input validation on any user data before it reaches database queries
• Consider temporarily restricting access to affected functionality while patches are applied

If upgrading is not immediately possible, refactor code to use the unaffected jsonfield.has_key lookup via the double-underscore syntax. Additionally, implement strict allow-listing of acceptable input values where user data must be used in JSON field lookups, and consider deploying a web application firewall with SQL injection protection rules as a defense-in-depth measure.