Description

An issue was discovered in Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18. `django.utils.translation.get_supported_language_variant()` is subject to a potential denial-of-service attack when processing many distinct, very long language codes, which are retained as keys in an in-memory cache and consume process memory. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Gleb Lizunov for reporting this issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-10-06T14:17:46.017Z",
  "pubdate": "2026-10-06T14:17:46.017Z",
  "executiveSummary": "A Denial-of-Service (DoS) vulnerability exists in the django.utils.translation.get_supported_language_variant() function within the Django web framework.\nThe issue stems from an unbounded memory growth vulnerability when processing maliciously crafted, long, or distinct language codes.\nAffected products include Django versions 6.1 (before 6.1.2), 6.0 (before 6.0.9), and 5.2 (before 5.2.18). Unsupported series such as 5.1.x, 5.0.x, and 4.2.x may also be susceptible.\nThe vulnerability allows an attacker to exhaust system memory by forcing the application to store a large volume of arbitrary, long language strings in an internal in-memory cache.\nSuccessful exploitation results in process-level memory exhaustion, leading to application crashes or instability.\nNo authentication or elevated privileges are required to reach the vulnerable code path, as the function is often exposed through standard request headers or locale negotiation mechanisms.",
  "technicalDetails": "The vulnerability resides in the internal caching mechanism utilized by django.utils.translation.get_supported_language_variant(). This function is designed to resolve requested language tags against a list of supported locales.\nRoot Cause: The function implementation caches the results of language variant resolution. When an application processes user-supplied input (such as the 'Accept-Language' HTTP header) as a language code, these inputs are used as keys in the internal cache. Because there is no validation or length constraint enforced on these language codes before they are inserted into the cache, an attacker can submit a high frequency of unique, excessively long, or randomized strings.\nAttack Flow: An attacker sends a series of HTTP requests to the target Django application, each containing a unique and lengthy 'Accept-Language' header value. The Django framework passes these values to get_supported_language_variant(). The function processes each unique string, fails to find a valid match, and subsequently caches the failed resolution attempt. Because these cache keys are retained in memory without an eviction strategy tailored for unbounded growth or size limiting, the process memory footprint increases monotonically.\nMemory Exhaustion: As the in-memory cache grows, the application process consumes increasing amounts of system RAM. If the attack is sustained, the system or container limits (e.g., OOM killer) will trigger, terminating the Django process. This results in a persistent DoS condition where the service becomes unavailable.\nScope: The vulnerability affects Django versions 6.1, 6.0, and 5.2 in the provided patch ranges. Due to the architectural nature of the flaw, older, end-of-life versions (4.2.x, 5.0.x, 5.1.x) are considered potentially impacted as the translation logic remains consistent across these iterations.\nExploitation requirements: The attacker requires network connectivity to the application server. The payload involves crafting high-entropy or long strings within locale-related headers or parameters that trigger language translation logic. No specific authentication or authorization tokens are necessary to trigger the cache insertion, as the resolution function is typically reachable via public-facing request processing."
}