Skip to main content
CVE-2024-53908VulnerabilityPublished

CVE-2024-53908: django · n/a

Affects djangoSource CVE Database V5

0

Not known to be exploited · CVSS 9.8 Critical · fixed in 5.1.4 : patch django as a priority.

Data as of 25 Oct 2026, 19:02 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
1.4% chance of exploitation in 30 days – higher than 72% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 5.1.4, 5.0.10, 4.2.17
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 6 Dec 2024

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.

What to do

Upgrade django to 5.1.4, 5.0.10 or 4.2.17.

Affected software

ProductAffectedFixed in
PyPIdjangopkg:pypi/djangoOther threatsAffected
  • <4.2.17
  • <5.0.10
  • <5.1.4
Fixed in
  • 4.2.17
  • 5.0.10
  • 5.1.4

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

To mitigate CVE-2024-53908, organizations should immediately upgrade Django to versions 5.1.4, 5.0.10, or 4.2.17 or later, where the vulnerability is patched. Avoid direct usage of django.db.models.fields.json.HasKey lookup with untrusted input, especially when using Oracle databases. Instead, use the jsonfield.has_key lookup via the double underscore syntax, which is not vulnerable. Conduct thorough code reviews to identify and refactor any direct HasKey usage with dynamic or user-supplied data. Implement strict input validation and sanitization on all inputs that interact with database queries. Employ Web Application Firewalls (WAFs) with SQL injection detection rules tailored for Oracle SQL syntax to provide an additional layer of defense. Monitor application logs and database query logs for suspicious activity indicative of SQL injection attempts. Finally, maintain an incident response plan ready to address potential exploitation attempts promptly.

Description

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.)

References

Community reviews

Loading reviews…