This vulnerability in Django's set_language() view allows memory exhaustion through repeated language parameter submissions. The advisory states memory is 'bounded by DATA_UPLOAD_MAX_MEMORY_SIZE' and 'a fixed maximum number of entries'—but these bounds create a dangerously misleading sense of security that masks real DoS risk in production deployments.
The critical misunderstanding: a 2.5MB per-request ceiling doesn't mean 2.5MB of acceptable risk. An attacker can issue repeated requests up to that threshold, and if the cache has no TTL or unbounded eviction policy, sustained traffic keeps it populated with attacker-chosen values. The actual DoS threshold depends on concurrent request capacity and worker count—not on the individual request limit.
Your exposure depends heavily on deployment architecture. If you're using LocMemCache (the default), each gunicorn or uWSGI worker maintains its own cache instance—the effective aggregate cache size scales linearly with worker count. A four-worker gunicorn deployment gives attackers four times the per-process ceiling. More critically, check_for_language() caches results in-process regardless of your configured cache backend; the Redis/Memcached distinction is largely irrelevant here because the attack fills Python process memory directly.
The 'not routed by default' qualifier compounds the risk. Sites that enable i18n—typically production applications with meaningful SLAs—are the ones exposing this view. The path from 'not default' to 'production attack surface' is trivial to cross, and the set_language() function has known genealogical vulnerability in prior Django series.
The advisory explicitly states 5.1.x, 5.0.x, and 4.2.x 'were not evaluated.' For organizations on Django's LTS track, this is material uncertainty. The 4.2.x extended support window means you face a patching decision without confirmation that the vulnerable code path exists or doesn't exist in your version. Historical patterns suggest 'not evaluated' often correlates with later discovery of vulnerability rather than genuine immunity.
Action: Verify your worker count and cache backend, enable TTL expiration on any cache storing language selections, and treat this as exploitable on any i18n-enabled deployment until proven otherwise.