Django EUVD-2026-116021

The target application must enable Django's server-side per-page caching - either django.middleware.cache.UpdateCacheMiddleware or the django.views.decorators.cache.cache_page() decorator - AND return responses whose Vary header lists a request header that clients can either omit or send with an empty value. Private or per-request data must actually be cached under such a Vary-keyed response for exposure to occur. Exploitation is limited by several factors: caching must be configured (not Django's default), the collision only occurs between an absent header and a present-but-empty header value, and the attacker cannot choose which victim's cached response they receive (reflected in AT:P and UI:P in the vendor vector). This makes successful disclosure opportunistic rather than deterministic.

All signals converge on low real-world risk. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:P/VC:L and all other impacts N) yields a base score of 2.3, Django's own security policy rates it 'low', and the vuln.today decision label is 'monitor' - none of which indicate urgency. The AT:P (attack requirements) and UI:P (passive user interaction) metrics reflect that exploitation is opportunistic rather than attacker-controlled: an attacker cannot reliably force a specific victim's private response to be served, they merely benefit from a cache-key collision between an absent and an empty Vary-listed header. Confidentiality impact is only Low (VC:L) with no integrity or availability impact. No EPSS score was supplied in the input, so exploitation probability cannot be quantified; this gap should be noted rather than assumed low or high. The CVE is not in CISA KEV and no public exploit or PoC reference is present - only vendor patch commits and release notes. There is no conflict between the network attack vector and the mechanism: the flaw is reachable over HTTP, but only against applications that have opted into Django's server-side page caching with a Vary header, which sharply narrows the exposed population.

An application uses Django's UpdateCacheMiddleware or the cache_page() decorator and returns responses that Vary on a request header (for example a region or language header) carrying per-user private content. Because a request that omits that header and a request that sends it empty previously produced identical cache keys, a private response cached for one visitor can be served to a different visitor whose request collides on the key. No public exploit code or PoC is identified; exploitation is opportunistic and depends on cache timing and traffic.