The vulnerability occurs when django.utils.translation.check_for_language() receives many distinct, very long language codes. These codes are stored as keys in an in-memory cache with a fixed size, so each new distinct code consumes additional RAM until the cache limit is reached. The excessive memory allocation can exhaust the application’s process memory and cause a denial of service. This weakness is classified as CWE‑789 (improper memory management) and CWE‑1050 (improper validation of pattern or model), posing a risk to the availability of affected Django applications.

The flaw affects Django 5.2 releases prior to 5.2.17 and Django 6.0 releases prior to 6.0.8. Earlier, not‑supported series such as 5.1.x, 5.0.x, and 4.2.x were not evaluated and may also be vulnerable. The issue surfaces when the check_for_language() function is invoked through the django.views.i18n.set_language() view, which is not included in the default URL configuration but can be exposed by an application developer.

The CVSS score of 6.9 indicates a medium severity for this issue. EPSS information is not available, but the potential impact relies on an attacker being able to call the set_language view. Since the view is not routed by default, a conscious attacker would need to expose it, which increases the effort required for exploitation. The memory usage is capped by the DATA_UPLOAD_MAX_MEMORY_SIZE setting (default 2.5 MB) and the cache size, so the denial of service is bounded but still significant for a busy application. The vulnerability is not listed in the CISA KEV catalog, which suggests that no widespread exploitation has been reported yet.