CVE-2025-13473: Django Auth Bypass Vulnerability

CVE-2025-13473 Overview

A timing attack vulnerability has been discovered in Django's django.contrib.auth.handlers.modwsgi.check_password() function used for authentication via mod_wsgi. This flaw allows remote attackers to enumerate valid usernames by analyzing response time differences when authentication attempts are made. The vulnerability affects Django versions 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28. Earlier unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.

Critical Impact

Remote attackers can enumerate valid usernames through timing analysis of authentication responses, potentially enabling targeted credential attacks against known user accounts.

Affected Products

• Django 6.0 before 6.0.2
• Django 5.2 before 5.2.11
• Django 4.2 before 4.2.28

Discovery Timeline

• 2026-02-03 - Django releases security patches and publishes advisory
• 2026-02-03 - CVE CVE-2025-13473 published to NVD
• 2026-02-04 - Last updated in NVD database

Technical Details for CVE-2025-13473

Vulnerability Analysis

This vulnerability is classified as CWE-208 (Observable Timing Discrepancy), a type of side-channel attack that exploits differences in processing time to infer sensitive information. The check_password() function in Django's mod_wsgi authentication handler exhibits observable timing differences depending on whether a username exists in the system or not.

When a valid username is provided, the system performs password hashing and comparison operations which take measurably longer than the quick rejection path for non-existent users. This timing discrepancy can be measured remotely across network connections, allowing attackers to systematically probe for valid usernames without triggering typical authentication failure rate limits.

Root Cause

The root cause lies in the django.contrib.auth.handlers.modwsgi.check_password() function not implementing constant-time comparison for all authentication paths. When processing authentication requests, the function takes different code paths depending on whether the supplied username exists in the system. The branch handling non-existent users returns more quickly than the branch that must retrieve user data and perform password verification, creating a measurable timing oracle.

Attack Vector

The attack is network-based and can be executed remotely against any Django application using mod_wsgi for authentication. An attacker would systematically send authentication requests with various usernames while precisely measuring response times. Statistical analysis of these timing measurements reveals which usernames correspond to valid accounts in the system.

The attack requires network access to the target application's authentication endpoint. While the timing differences may be small, they can be amplified through repeated measurements and statistical techniques. Once valid usernames are enumerated, attackers can focus password guessing, credential stuffing, or social engineering attacks on confirmed accounts.

Detection Methods for CVE-2025-13473

Indicators of Compromise

• Unusual patterns of authentication failures across many different usernames from the same source IP
• High volume of authentication requests with sequential or dictionary-based username patterns
• Network traffic analysis showing systematic timing measurement patterns against authentication endpoints
• Authentication logs showing rapid succession of failed login attempts with varying usernames

Detection Strategies

• Implement authentication request rate limiting and anomaly detection at the application or WAF level
• Monitor authentication logs for patterns indicative of enumeration attempts (many unique usernames from single sources)
• Deploy network intrusion detection rules to identify timing attack patterns
• Use application performance monitoring to detect unusual authentication endpoint response time analysis

Monitoring Recommendations

• Enable detailed logging for all mod_wsgi authentication events including timestamps and source IPs
• Set up alerts for authentication failure rates exceeding normal thresholds
• Monitor for reconnaissance activity patterns in web application firewall logs
• Implement user behavior analytics to detect systematic probing attempts

How to Mitigate CVE-2025-13473

Immediate Actions Required

• Upgrade Django to version 6.0.2, 5.2.11, or 4.2.28 depending on your installed series
• Review authentication logs for evidence of prior enumeration attempts
• Implement additional rate limiting on authentication endpoints as a defense-in-depth measure
• Consider temporarily disabling mod_wsgi authentication in favor of alternative authentication methods if immediate patching is not possible

Patch Information

Django has released security patches addressing this vulnerability across all supported versions. The fixed versions implement constant-time comparison techniques to eliminate observable timing differences between valid and invalid username authentication paths. Upgrade to the following patched versions:

• Django 6.0.2 for 6.0.x series
• Django 5.2.11 for 5.2.x series
• Django 4.2.28 for 4.2.x series

For detailed patch information and upgrade instructions, refer to the Django Security Release Notes and the Django Security Releases announcement.

Workarounds

• Implement network-level rate limiting on authentication endpoints to slow down timing analysis attempts
• Deploy a web application firewall (WAF) with rules to detect and block enumeration patterns
• Use alternative authentication mechanisms that do not rely on mod_wsgi until patching is complete
• Consider implementing CAPTCHA or other challenge-response mechanisms to prevent automated enumeration

# Configuration example - Rate limiting in Apache for mod_wsgi endpoints
# Add to Apache configuration to limit authentication requests
<Location "/auth">
    # Limit requests to 10 per minute per IP
    SetEnvIf Request_URI "^/auth" rate_limit
    <RequireAll>
        Require all granted
    </RequireAll>
</Location>

# Enable mod_ratelimit if available
# LoadModule ratelimit_module modules/mod_ratelimit.so