CVE-2026-25674

What it actually does

This vulnerability is a race condition in Django's file-system storage and file-based cache backends. In affected Django versions, one request thread can temporarily change the process umask while creating files, and that temporary setting can unintentionally affect another concurrent thread in the same multi-threaded application process. The result is that files or cache objects may be created with permissions that are more permissive than intended. The primary technical risk is limited confidentiality exposure of files that should have been restricted by filesystem permissions; the flaw does not directly provide code execution, privilege escalation, or data modification.

Why it matters to the business

Applications using affected Django versions may create uploaded files, generated files, or file-based cache entries with unsafe permissions during periods of concurrent request activity. In practical terms, this can expose sensitive local files to other users, processes, containers, or services that share the same filesystem boundary. The assessed severity is low, exploitation requires favorable timing and concurrency, EPSS is low, and it is not currently listed in CISA KEV or known ransomware use; however, Django is widely deployed, so organizations should still patch during normal security maintenance, especially where file uploads, generated reports, exports, or file-based caching may contain sensitive data.

How an attack unfolds

An attacker first identifies a Django application running an affected version and determines whether reachable functionality causes Django to create files through the file-system storage backend or file-based cache backend. The attacker then sends carefully timed concurrent requests that trigger file creation operations. Because the application runs in a multi-threaded process, one request thread may temporarily modify the process umask while another thread is also creating a file. If the timing is successful, the second file may be created with broader permissions than intended. The attacker then attempts to access or benefit from those overly permissive filesystem objects through another local account, shared process, misconfigured static/media serving path, shared volume, backup process, or other path that can read files based on filesystem permissions. Exploitation is timing-dependent and environment-dependent, which is why attack complexity is high.

How to fix it

Upgrade Django to a fixed supported version: upgrade 6.0.x to 6.0.3 or later, 5.2.x to 5.2.12 or later, and 4.2.x to 4.2.29 or later. If running an unsupported Django series such as 5.0.x, 4.1.x, or 3.2.x, migrate to a supported fixed release because those branches were not evaluated and may also be affected. As defense in depth, avoid storing sensitive data in file-based cache entries, restrict filesystem permissions on media/cache directories, isolate application runtime users, avoid sharing writable storage across trust boundaries, and review web server rules to ensure private storage paths are not directly served. Where immediate patching is not possible, reduce exposure by disabling file-based cache backends for sensitive content, moving sensitive storage to a backend with stronger access controls, or running with process isolation that prevents untrusted users or services from reading application-created files.

How to confirm the fix worked

Confirm the installed Django version using package inventory, dependency lockfiles, container image manifests, or runtime checks such as `python -m django --version` or `pip show Django`. Validate that all deployments are on Django 6.0.3 or later, 5.2.12 or later, 4.2.29 or later, or another supported release containing the fix. Review dependency pins in `requirements.txt`, `poetry.lock`, `Pipfile.lock`, `uv.lock`, container build files, and CI artifacts to ensure older vulnerable versions are not reintroduced. For exposure validation, identify whether the application uses Django file-system storage or file-based cache backends and whether it runs multi-threaded workers. Inspect file upload, media, generated-file, and cache directories for unexpectedly permissive modes, especially files created before patching. After upgrading, run functional tests that create uploads and cache files under concurrent load and verify resulting file permissions match the intended policy.

Typical attack path

1. Identify a Django application running an affected release: 6.0 before 6.0.3, 5.2 before 5.2.12, or 4.2 before 4.2.29; unsupported series may also be affected.
2. Find application functionality that creates files, such as uploads, generated documents, exports, thumbnails, temporary files, or file-based cache entries.
3. Generate concurrent requests against those functions to increase the likelihood of overlapping file creation operations in separate threads.
4. Exploit the race condition where one thread's temporary umask affects another thread's file creation permissions.
5. Check whether newly created files or cache entries have group-readable or world-readable permissions that should not be present.
6. Attempt to read exposed content through local filesystem access, a shared volume, a misconfigured static/media route, another service account, backups, or other mechanisms that honor filesystem permissions.

How to detect it

There is no reliable network-only indicator for exploitation because this issue depends on request timing and local filesystem side effects. To investigate possible prior exploitation, correlate web server access logs, application logs, WSGI/ASGI worker logs, and file audit telemetry around periods of high request concurrency to endpoints that create uploads, generated files, media, or file-based cache entries. Look for bursts of repeated requests from the same source or small group of sources to file-creation endpoints, followed by creation of files with unexpectedly permissive modes. On Linux, use auditd, EDR file telemetry, filesystem metadata, backup indexes, or forensic timelines to identify files created by the Django application process with modes broader than policy, such as world-readable or group-readable files in directories expected to contain private data. Review whether any local users, colocated services, sync agents, static file servers, or backup jobs accessed those files after creation. Because no public exploit maturity is reported and the vulnerability is not in KEV, absence of clear indicators is expected; focus detection on permission anomalies and suspicious concurrency rather than a fixed exploit signature.

What your security team should do

• Inventory all applications and container images using Django and prioritize those on 6.0.x, 5.2.x, 4.2.x, or unsupported branches.
• Patch to Django 6.0.3, 5.2.12, 4.2.29, or a later supported fixed release during the next security update cycle.
• Prioritize externally reachable applications that support file uploads, generated downloads, report exports, media processing, or file-based caching.
• Replace or restrict file-based cache usage where sensitive data may be written to disk.
• Audit media, upload, temporary, generated-file, and cache directories for files with overly broad permissions, especially group-readable or world-readable sensitive files.
• Ensure private storage paths are not directly exposed through web server static file mappings or object synchronization jobs.
• Run application services under least-privilege operating system accounts and avoid shared writable volumes across trust boundaries.
• Add dependency governance checks so unsupported Django series and vulnerable fixed-version ranges fail builds or deployment gates.