This vulnerability in Django affects the check_for_language() function that caches language codes in memory. When an attacker supplies many distinct, very long language codes through the set_language() view, the in-memory cache grows, consuming excessive memory and potentially causing a denial-of-service. The attack surface is limited because the set_language() view is not routed by default and request size is capped by DATA_UPLOAD_MAX_MEMORY_SIZE (default 2.5 MB). The cache also holds a fixed maximum number of entries, bounding memory use. The issue affects Django 5.2 versions prior to 5.2.17 and 6.0 versions prior to 6.0.8. No official remediation level or patch links are provided in the data, so patch status is not confirmed. Earlier unsupported versions may also be vulnerable but were not assessed.

The impact is a denial-of-service condition caused by excessive memory consumption in the Django process. This can degrade service availability but does not affect confidentiality or integrity. The attack requires sending many distinct, very long language codes to the set_language() view, which is not enabled by default, limiting exposure. Memory consumption is bounded by request size limits and cache size, reducing the risk of complete system failure.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Since the set_language() view is not routed by default, disabling or not enabling this view reduces exposure. Additionally, the default DATA_UPLOAD_MAX_MEMORY_SIZE setting limits request size, bounding memory consumption. Monitor vendor channels for official patches or updates and apply them once available.