CVE-2026-15337: Django Denial-of-Service Vulnerability in Language Check Function
Summary
CVE-2026-15337: Potential denial-of-service vulnerability in check_for_language(). Affects django across 2 version ranges.
< 5.2.17
>= 6.0.0, < 6.0.8
Fixed in 5.2.17 or 6.0.8, depending on the release line you run. How to fix ↓
Check if this vulnerability affects your application
Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.
No signup required · Results in about 60 seconds
Background
Django is a high-level Python web framework that encourages rapid development and clean, pragmatic design. It is widely used for building web applications and provides a robust set of features, including an ORM, authentication, and internationalization support. The framework's translation module allows developers to manage multiple languages in their applications. However, certain versions of Django are vulnerable to a denial-of-service attack due to improper handling of language codes.
Vulnerability Detail
An issue was discovered in Django versions 5.2 before 5.2.17 and 6.0 before 6.0.8, where the function django.utils.translation.check_for_language() can be exploited by providing many distinct, very long language codes. These codes are stored in an in-memory cache, leading to excessive memory consumption. The vulnerability can be triggered through the django.views.i18n.set_language() view, which is not routed by default. Although the memory usage is limited by the DATA_UPLOAD_MAX_MEMORY_SIZE setting, the potential for denial-of-service remains significant, especially in environments with constrained resources.
How To Fix
Fixed versions by release line
The minimum fixed version depends on the release line you run.
-
< 5.2.175.2.17 -
>= 6.0.0, < 6.0.86.0.8
Tip — Not sure which release line you're on? Vulert can find the fix for the version you are using. Scan free →
Workaround
As a temporary workaround, you can limit the length of language codes accepted by your application or disable the set_language view if it is not needed. This can be done by modifying your URL routing or by implementing validation logic in your views.
Conclusion
The identified vulnerability in Django poses a risk of denial-of-service attacks due to improper handling of language codes. It is crucial for developers using affected versions to update to the patched releases to mitigate this risk. Additionally, implementing workarounds can provide temporary relief until an update can be performed.
See every vulnerability recorded for django →
FAQ
Django versions 5.2 before 5.2.17 and 6.0 before 6.0.8 are affected. Earlier unsupported versions may also be vulnerable.
A denial-of-service attack aims to make a service unavailable to its intended users by overwhelming it with requests or exploiting vulnerabilities.
You can use Vulert, which monitors open-source vulnerabilities in your software. Visit Vulert Scanner to check your application without needing to sign up.
If an immediate update is not possible, consider implementing input validation to restrict the length of language codes or disabling the set_language view.
Django would like to thank Jaeyoung Jang for reporting this issue.
Related vulnerabilities
Recent vulnerabilities recorded for django.