CVE-2026-77050

Django's django.utils.translation.get_supported_language_variant() stores every distinct language code it processes as a key in an in-memory cache without any size limit (CWE-789). An unauthenticated attacker can trigger this by sending many requests containing unique, very long language codes — most commonly crafted Accept-Language headers on sites that perform language negotiation, such as those using LocaleMiddleware — and each new code is retained in the cache, consuming process memory. The impact is denial of service only: worker processes can be degraded or OOM-killed as memory fills, but there is no impact on confidentiality or integrity (CVSS 4.0 base 6.9, availability-only). Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18 are affected, and older unsupported series (5.1.x, 5.0.x, 4.2.x) were not evaluated and may also be vulnerable. There is no public proof of concept, the issue is not in the CISA KEV catalog, and no exploitation has been reported.

What to do: Upgrade to the fixed release for your series: Django 6.1.2, 6.0.9, or 5.2.18; if you are on an unsupported series (5.1, 5.0, 4.2), move to a supported patched release since fixes will not be backported. As interim mitigation, cap or reject oversized Accept-Language headers (and requests with unusually many/long language tags) at your reverse proxy or WAF, and consider periodic worker recycling plus memory monitoring to detect cache bloat. Verify whether your site enables LocaleMiddleware or otherwise calls get_supported_language_variant() to confirm actual exposure.