CVE-2026-25674: Django Race Condition Vulnerability

CVE-2026-25674 Overview

A race condition vulnerability has been discovered in Django's file-system storage and file-based cache backends. This vulnerability allows an attacker to cause file system objects to be created with incorrect permissions via concurrent requests, where one thread's temporary umask change affects other threads in multi-threaded environments.

The issue affects Django versions 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29. 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

In multi-threaded Django deployments, concurrent file operations may result in files being created with unintended permissions, potentially exposing sensitive data or allowing unauthorized file access.

Affected Products

• Django 6.0.0 through 6.0.2
• Django 5.2.0 through 5.2.11
• Django 4.2.0 through 4.2.28

Discovery Timeline

• 2026-03-03 - CVE-2026-25674 published to NVD
• 2026-03-05 - Last updated in NVD database

Technical Details for CVE-2026-25674

Vulnerability Analysis

This vulnerability is classified as a Race Condition (CWE-362), specifically affecting the file-system storage and file-based cache backends in Django. The root cause lies in how Django temporarily modifies the process-wide umask value during file creation operations.

In a multi-threaded environment, when one thread changes the umask to create a file with specific permissions, other threads executing concurrently may inherit this modified umask value. This creates a Time-of-Check Time-of-Use (TOCTOU) scenario where the intended file permissions are not consistently applied.

The vulnerability requires high attack complexity due to the precise timing needed to exploit the race condition. While the network attack vector is available, successful exploitation depends on the attacker's ability to trigger concurrent file operations that align with the vulnerable window.

Root Cause

The underlying issue stems from the umask system call being process-wide rather than thread-local. When Django's file storage or cache backend modifies the umask to set specific file permissions, this change affects all threads in the process simultaneously. During concurrent file creation operations, threads may inadvertently use a umask value set by another thread, resulting in files being created with incorrect permissions.

Attack Vector

An attacker can exploit this vulnerability by sending concurrent requests to a Django application that uses file-system storage or file-based caching. In scenarios where:

1. Multiple threads handle simultaneous file upload or cache operations
2. One thread temporarily modifies the umask for a file creation operation
3. Another thread creates a file during this window

The second thread's file may be created with the wrong permissions, potentially making sensitive files readable or writable by unauthorized users. This could lead to information disclosure if files intended to be private become accessible.

Detection Methods for CVE-2026-25674

Indicators of Compromise

• Unexpected file permission changes on Django-managed storage directories
• Files in cache directories with permissions that deviate from expected configuration
• Inconsistent permission patterns across files created at similar times
• Log entries indicating file access from unauthorized processes or users

Detection Strategies

• Audit file permissions on Django file storage directories for anomalies
• Monitor for files created with overly permissive modes (e.g., world-readable)
• Implement file integrity monitoring on cache and media directories
• Review Django application logs for concurrent file operation patterns

Monitoring Recommendations

• Enable detailed logging for file system operations in Django applications
• Configure alerts for permission changes on sensitive storage directories
• Implement periodic permission audits using automated scripts
• Monitor thread concurrency metrics in multi-threaded Django deployments

How to Mitigate CVE-2026-25674

Immediate Actions Required

• Upgrade Django to version 6.0.3, 5.2.12, or 4.2.29 immediately
• Review file permissions in existing storage and cache directories for anomalies
• Consider temporarily switching to database-backed cache if immediate patching is not possible
• Audit applications for concurrent file operation patterns that may have been affected

Patch Information

Django has released security patches addressing this vulnerability. Upgrade to the following fixed versions:

• Django 6.0.x: Upgrade to version 6.0.3 or later
• Django 5.2.x: Upgrade to version 5.2.12 or later
• Django 4.2.x: Upgrade to version 4.2.29 or later

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

Workarounds

• Switch from file-based caching to database or memory-based cache backends
• Run Django in single-threaded mode (process-based workers) if feasible
• Set restrictive directory-level permissions to limit exposure from individual file permission errors
• Implement external file permission enforcement using OS-level access controls

# Upgrade Django to patched version
pip install --upgrade Django>=6.0.3

# Verify installed version
python -c "import django; print(django.VERSION)"

# Alternative: Switch to database cache backend in settings.py
# CACHES = {
#     'default': {
#         'BACKEND': 'django.core.cache.backends.db.DatabaseCache',
#         'LOCATION': 'django_cache_table',
#     }
# }