Cloudanix VulnDB

CVE-2024-53908

Critical · 9.8

Django SQL injection in HasKey(lhs, rhs) on Oracle

CVSS

9.8

EPSS

1.4%

Published

Dec 6, 2024

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A web framework bug lets attackers tamper with database queries on Oracle systems when certain lookup features receive untrusted input, risking unauthorized data access.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Data Exposure
Component
Web Framework
Class
SQL Injection
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Direct use of django.db.models.fields.json.HasKey lookup against Oracle allows SQL injection when untrusted data is supplied as the lhs value, enabling arbitrary SQL execution.

Why it matters to the business

Attackers may read, modify, or delete database contents, leading to data breaches, compliance violations, and service disruption; urgency is moderate given low EPSS and absence from known exploited lists despite high CVSS.

How an attack unfolds

An attacker supplies a malicious string as the left-hand side value to a direct HasKey lookup in an ORM query running against Oracle; the unsanitized input is concatenated into the generated SQL statement, allowing injection of additional clauses or commands.

How to fix it

Upgrade Django to 5.1.4+, 5.0.10+, or 4.2.17+; the patch is present in commit 3b3a5f4efbf93692557b7f473519bd0ad8f04c6a. Avoid direct HasKey usage with untrusted lhs values on Oracle until patched.

How to confirm the fix worked

Confirm Django version is at or above the fixed releases, review ORM queries for direct HasKey calls, and test affected lookups against an Oracle backend with both benign and attempted injection inputs.

Typical attack path

  1. Identify application code paths that invoke HasKey directly with user-controlled data
  2. Craft input containing SQL metacharacters or subqueries targeting Oracle syntax
  3. Submit the payload through the affected request or API endpoint
  4. Observe database error responses or extracted data to confirm and escalate the injection

How to detect it

Search application and database logs for queries containing HasKey with unusual lhs values or Oracle-specific error patterns indicating malformed JSON path expressions; review audit trails for unexpected data access following ORM calls.

What your security team should do

  • Immediately inventory Django deployments using Oracle and direct HasKey lookups
  • Apply the listed patch releases or commit within the next sprint
  • Add static analysis or code review rules to flag direct HasKey usage
  • Monitor EPSS and KEV updates for any rise in exploitation activity

The record

An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. Direct usage of the django.db.models.fields.json.HasKey lookup, when an Oracle database is used, is subject to SQL injection if untrusted data is used as an lhs value. (Applications that use the jsonfield.has_key lookup via __ are unaffected.)

Affected packages

Ecosystem Package Introduced Fixed
PyPI django 4.2 4.2.17
PyPI django 4.2.0 4.2.17
PyPI django 5.0 5.0.10
PyPI django 5.0.0 5.0.10
PyPI django 5.1 5.1.4
PyPI django 5.1.0 5.1.4
Bitnami django 4.2.0 4.2.17
Chainguard awx 0 24.6.1-r2
Chainguard py3-django 0 5.1.4-r0
Chainguard py3-supported-django 0 5.1.4-r0
Chainguard py3.10-django 0 5.1.4-r0
Chainguard py3.10-django-bin 0 5.1.4-r0
Chainguard py3.11-django 0 5.1.4-r0
Chainguard py3.11-django-bin 0 5.1.4-r0
Chainguard py3.12-django 0 5.1.4-r0
Chainguard py3.12-django-bin 0 5.1.4-r0
Chainguard py3.13-django 0 5.1.4-r0
Chainguard py3.13-django-bin 0 5.1.4-r0
Debian:12 python-django 0 No fix
Debian:13 python-django 0 3:4.2.17-1
Debian:14 python-django 0 3:4.2.17-1
Mageia:9 python-django 0 4.1.13-1.2.mga9
Red Hat:ansible_automation_platform:2.5::el8 automation-controller-venv-tower 0 0:4.6.6-1.el8ap
Red Hat:ansible_automation_platform:2.5::el8 automation-gateway-server 0 0:2.5.20250115-1.el8ap
Red Hat:ansible_automation_platform:2.5::el8 python3.11-aiohttp 0 0:3.10.11-1.el8ap
Red Hat:ansible_automation_platform:2.5::el8 python3.11-aiohttp-debuginfo 0 0:3.10.11-1.el8ap
Red Hat:ansible_automation_platform:2.5::el8 python3.11-aiohttp-debugsource 0 0:3.10.11-1.el8ap
Red Hat:ansible_automation_platform:2.5::el9 automation-controller-venv-tower 0 0:4.6.6-1.el9ap
Red Hat:ansible_automation_platform:2.5::el9 automation-gateway-server 0 0:2.5.20250115-1.el9ap
Red Hat:ansible_automation_platform:2.5::el9 python3.11-aiohttp 0 0:3.10.11-1.el9ap
Red Hat:ansible_automation_platform:2.5::el9 python3.11-aiohttp-debuginfo 0 0:3.10.11-1.el9ap
Red Hat:ansible_automation_platform:2.5::el9 python3.11-aiohttp-debugsource 0 0:3.10.11-1.el9ap
Red Hat:ansible_automation_platform_developer:2.5::el8 automation-controller-venv-tower 0 0:4.6.6-1.el8ap
Red Hat:ansible_automation_platform_developer:2.5::el9 automation-controller-venv-tower 0 0:4.6.6-1.el9ap
SUSE:Linux Enterprise Module for Package Hub 15 SP6 python-Django 0 4.2.11-150600.3.12.1
Ubuntu:20.04:LTS python-django 0 2:2.2.12-1ubuntu0.26
Ubuntu:22.04:LTS python-django 0 2:3.2.12-2ubuntu1.15
Ubuntu:24.04:LTS python-django 0 3:4.2.11-1ubuntu1.4
Ubuntu:24.10 python-django 0 3:4.2.15-1ubuntu1.1
Wolfi py3-django 0 5.1.4-r0
Wolfi py3-supported-django 0 5.1.4-r0
Wolfi py3.10-django 0 5.1.4-r0
Wolfi py3.10-django-bin 0 5.1.4-r0
Wolfi py3.11-django 0 5.1.4-r0
Wolfi py3.11-django-bin 0 5.1.4-r0
Wolfi py3.12-django 0 5.1.4-r0
Wolfi py3.12-django-bin 0 5.1.4-r0
Wolfi py3.13-django 0 5.1.4-r0
Wolfi py3.13-django-bin 0 5.1.4-r0
openSUSE:Leap 15.6 python-Django 0 4.2.11-150600.3.12.1
openSUSE:Tumbleweed python-Django 0 5.1.4-1.1
openSUSE:Tumbleweed python-Django4 0 4.2.17-1.1
openSUSE:Tumbleweed python-Django6 0 6.0-1.1
pypi Django 4.2.0 No fix
pypi Django 5.0.0 No fix
pypi Django 5.1.0 No fix

Related vulnerabilities