The flaw resides in Django’s cache header handling routine. The function used to determine whether a cached response matches a new request compares the Vary header values without trimming any leading or trailing whitespace. Because the comparison does not discard padding, responses that differ only by whitespace are treated as distinct cache entries. By sending a request to a URL whose response contains a whitespace‑padded Vary header, an attacker can retrieve a cached response that was not intended for public consumption. The vulnerability allows remote parties to read private or sensitive data that has been cached by the application, without requiring authentication or elevated privileges, thereby exposing confidential information.

The issue affects Django branches 5.2.x before 5.2.15 and 6.0.x before 6.0.6. Older, unsupported series such as 5.0.x, 4.1.x, and 3.2.x were not evaluated, but they might contain the same code path and therefore could also be impacted.

The CVSS score of 2.3 indicates a low severity. No EPSS score is available, and the vulnerability is not listed in CISA KEV, suggesting limited exploitation in the wild. The attack is remote; any user with the ability to send HTTP requests to a Django application can potentially exploit the flaw. The risk is modest but the impact is the disclosure of data that was once protected by caching rules.