Skip to main content
CVE-2025-13473VulnerabilityPublished

CVE-2025-13473: djangoproject Django · Timing Side Channel

Affects djangoproject DjangoSource CVE Database V5

0

Not known to be exploited · CVSS 5.3 Medium · fixed in 6.0.2 : update djangoproject Django when convenient.

Data as of 25 Oct 2026, 19:02 UTC

CVSS 3.1 base score
5.3Medium
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.8% chance of exploitation in 30 days – higher than 56% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 6.0.2, 5.2.11, 4.2.28
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 3 Feb 2026

  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 and django to 6.0.2, 5.2.11 or 4.2.28.

Affected software

ProductAffectedFixed in
djangoprojectDjangoAffected
  • >=6.0 <6.0.2
  • >=5.2 <5.2.11
  • >=4.2 <4.2.28
Fixed in
  • 6.0.2
  • 5.2.11
  • 4.2.28
PyPIdjangopkg:pypi/djangoOther threatsAffected
  • =4.2
  • =5.2
  • =6.0
Fixed in–
PyPIdjangopkg:pypi/djangoOther threatsAffected
  • >=6.0 <6.0.2
  • >=5.2 <5.2.11
  • >=4.2 <4.2.28
Fixed in
  • 6.0.2
  • 5.2.11
  • 4.2.28

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-2025-13473, organizations should promptly upgrade Django to versions 6.0.2 or later, 5.2.11 or later, and 4.2.28 or later, where the vulnerability has been patched. If immediate upgrading is not feasible, implementing additional rate limiting on authentication endpoints can reduce the feasibility of timing attacks by limiting the number of authentication attempts from a single source. Employing consistent response times for authentication failures can help obscure timing discrepancies, though this may require custom middleware or patches. Monitoring authentication logs for unusual patterns of failed login attempts or username enumeration attempts is critical for early detection. Additionally, consider deploying Web Application Firewalls (WAFs) configured to detect and block suspicious timing attack patterns. Educating developers to avoid leaking timing information in authentication flows and reviewing custom authentication handlers for similar issues is recommended. Finally, ensure that multi-factor authentication (MFA) is enabled to reduce the impact of compromised credentials obtained through enumeration and brute force.

Description

An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28. The `django.contrib.auth.handlers.modwsgi.check_password()` function for authentication via `mod_wsgi` allows remote attackers to enumerate users via a timing attack. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Stackered for reporting this issue.

References

Community reviews

Loading reviews…