CVE-2026-35193
Authorization Header Bypass in Django Cache Middleware
Publication date: 2026-06-03
Last updated on: 2026-06-03
Assigner: Django Software Foundation
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| django | django | to 5.2.15 (exc) |
| django | django | to 6.0.6 (exc) |
| django | django | 5.0 |
| django | django | 4.1 |
| django | django | 3.2 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-524 | The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows remote attackers to read private cached responses via unauthenticated requests to the same URL because the Authorization header is not added to the Vary response header. This could lead to unauthorized disclosure of sensitive information.
Such unauthorized access to private data may impact compliance with data protection regulations like GDPR and HIPAA, which require strict controls on access to personal and sensitive information.
Organizations using affected Django versions should consider this vulnerability as a risk to confidentiality and take appropriate mitigation steps to maintain compliance.
Can you explain this vulnerability to me?
This vulnerability exists in Django versions 5.2 before 5.2.15 and 6.0 before 6.0.6. The issue is that the UpdateCacheMiddleware in Django does not add the Authorization header to the Vary response header when the request includes an Authorization header but does not have Cache-Control set to public.
Because of this, private cached responses that should be protected can be read by remote attackers through unauthenticated requests to the same URL.
How can this vulnerability impact me? :
This vulnerability can allow remote attackers to access private cached content without authentication by exploiting the missing Authorization header in the Vary response header.
As a result, sensitive or private information intended only for authorized users could be exposed to unauthorized parties.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves Django's caching middleware not adding the Authorization header to the Vary response header, which can allow unauthorized access to cached private responses.
To detect this vulnerability on your system, you can inspect HTTP responses from your Django application to see if the Vary header includes Authorization when requests contain the Authorization header without Cache-Control: public.
A practical approach is to use command-line tools like curl to send requests with Authorization headers and analyze the response headers.
- Use curl to send a request with an Authorization header and check the Vary header in the response: curl -I -H "Authorization: Bearer <token>" https://your-django-app/path
- Verify if the Vary header in the response includes 'Authorization'. If it does not, your system may be vulnerable.
- Additionally, check if Cache-Control is set to public or not, as the issue occurs when Cache-Control is not public.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to upgrade Django to a fixed version where this issue is resolved.
- Upgrade Django to version 5.2.15 or later if you are using the 5.2 series.
- Upgrade Django to version 6.0.6 or later if you are using the 6.0 series.
If upgrading immediately is not possible, consider configuring your caching and middleware settings to ensure that Authorization headers are properly handled and that private responses are not cached or served to unauthorized users.