Django EUVD-2026-34090

The CVSS 4.0 AT:P prerequisite requires that the target Django application emits HTTP responses where Vary header values contain leading or trailing whitespace (e.g., Vary: ' Cookie' or Vary: 'Accept-Encoding '). This is not produced by Django itself under default configuration and would typically originate from custom middleware performing manual header manipulation, a misconfigured reverse proxy or CDN injecting or modifying Vary headers, or non-standard response construction in application code. Additionally, UI:P (user interaction) is required per the CVSS vector. Exploitation is bounded to low confidentiality impact only (VC:L) - no integrity or availability impact is possible. Applications that do not use HTTP caching, do not emit Vary headers, or whose Vary values are never whitespace-padded are not exploitable regardless of Django version.

The CVSS 4.0 base score of 2.3 accurately reflects the limited real-world risk. The vector AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N indicates the vulnerability is network-reachable and requires no authentication (PR:N), but is significantly bounded by two key factors: AT:P (Attack Prerequisites required - the application must produce Vary headers with leading or trailing whitespace, which is atypical and non-default) and UI:P (user interaction required). Confidentiality impact is low (VC:L), with zero integrity or availability impact. No EPSS score was provided in the input data, so exploitation probability cannot be quantified from that signal. The vulnerability is not listed in CISA KEV, and no POC is identified. This combination - non-default prerequisite, user interaction required, low confidentiality-only impact, no active exploitation signal - places this squarely in the low-priority tier: patch as part of routine maintenance rather than emergency response. Applications not using HTTP caching infrastructure, or not emitting whitespace-padded Vary headers, carry no exploitable exposure.

An attacker identifies a Django application sitting behind a shared HTTP cache layer where certain responses include whitespace-padded Vary headers (e.g., Vary: Cookie with a leading space) due to custom middleware or a misconfigured upstream proxy. By issuing requests to URLs whose responses match the malformed cache key variant, the attacker can cause the cache to serve a previously stored response originally intended for a different user's context, exposing low-sensitivity cached content such as partial page fragments or API responses. No public exploit code is identified; exploitation requires the specific non-default condition of whitespace-padded Vary headers being present in live application responses.