CVE-2026-35193: Django Cache Middleware Leaks Private User Data via Unauthenticated Requests

Technical summary

The vulnerability exists in `django.middleware.cache.UpdateCacheMiddleware`. The middleware fails to include `Authorization` in the `Vary` response header when a request carries an `Authorization` header and lacks `Cache-Control: public`. The `Vary` header tells cache systems (browser cache, CDN, intermediaries) that responses for this URL differ based on the listed criteria. Without `Authorization` in `Vary`, a cache cannot distinguish between responses meant for authenticated users versus unauthenticated users. Consequently, an unauthenticated request can retrieve a cached response originally generated for an authenticated user, violating the intended caching semantics. This is classified as improper cache neutralization of sensitive information (CWE-524).

Business impact

If a Django application caches sensitive user data—account details, medical records, financial information, or any personalized content—an attacker can access it without authentication by requesting the same URL after an authenticated user has visited it. This directly violates confidentiality and may trigger regulatory compliance violations (GDPR, HIPAA, PCI-DSS) if user data is exposed. The impact is magnified in shared hosting, CDN, or proxy scenarios where cache is shared across multiple users or organizations.

Affected systems

Django 5.2 versions before 5.2.15 and Django 6.0 versions before 6.0.6 are confirmed vulnerable. Django 5.0.x, 4.1.x, and 3.2.x are noted as unsupported series that have not been formally evaluated but may be affected; organizations running these older versions should test and patch proactively. The vulnerability only manifests when `UpdateCacheMiddleware` is enabled in the application's middleware stack.

Exploitability

Exploitation requires that (1) the target Django application uses `UpdateCacheMiddleware`, (2) the application caches responses to authenticated requests, and (3) an attacker can identify a URL that serves sensitive content. No authentication or special privileges are required; the attacker simply makes an unauthenticated GET request to a cached URL. The CVSS score of 3.1 (LOW) reflects the requirement that user interaction or specific application configurations must be present, but the underlying logic flaw is straightforward to exploit once conditions align. This is not a widely exploitable vulnerability in its current form but poses real risk to applications using aggressive caching strategies.

Remediation

Upgrade to Django 5.2.15 or later for the 5.2 series, or Django 6.0.6 or later for the 6.0 series. If you cannot upgrade immediately, audit your cache configuration: disable `UpdateCacheMiddleware` if possible, or ensure that authenticated responses are explicitly marked `Cache-Control: private` or equivalent. Review middleware ordering and cache headers to confirm sensitive data is not being cached for unauthenticated access. For unsupported Django versions (5.0.x, 4.1.x, 3.2.x), assess risk tolerance and plan a migration to a supported version.

Patch guidance

1. Check your Django version with `python -m django --version`. 2. For Django 5.2.x: upgrade to 5.2.15 or later. 3. For Django 6.0.x: upgrade to 6.0.6 or later. 4. Verify the patch by testing your application's cache behavior: confirm that authenticated requests do not leak cached data to unauthenticated clients. 5. Review your cache middleware configuration in `settings.py` and ensure `Cache-Control` headers are properly set on sensitive views. 6. If running an older unsupported version, verify the advisory and test patched versions in a staging environment before production deployment.

Detection guidance

Monitor for signs of cache-based data leakage: (1) Review access logs for unauthenticated requests followed by successful data retrieval (status 200) to endpoints that should require authentication. (2) Check cached responses in your CDN or cache store for presence of `Authorization` in the `Vary` header. (3) Audit middleware configuration to confirm `UpdateCacheMiddleware` is in use and its interaction with authentication middleware. (4) Enable Django security logging and watch for unexpected cache hits on authenticated endpoints. (5) Conduct manual testing: authenticate, visit a sensitive URL, then clear cookies and request the same URL; if private data is returned, the vulnerability exists. Tools like curl with `-H` flag can verify response headers and cache directives.

Why prioritize this

While the CVSS score is LOW (3.1), this vulnerability should not be dismissed. It directly undermines confidentiality for any cached user data. Organizations with strict data protection requirements, PCI-DSS, HIPAA, or GDPR compliance obligations, or those serving sensitive financial or healthcare data should prioritize this patch immediately. Even for lower-risk environments, the fix is straightforward and should be included in the next patching cycle. The vulnerability is passive and does not enable active exploitation in the wild, but it represents a silent data leak risk that could persist undetected.

Risk score, explained

The CVSS 3.1 score of 3.1 (LOW severity) is driven by: Attack Vector (Network) = higher impact potential; Attack Complexity (High) = requires specific middleware configuration and caching strategy; Privileges Required (None) = no auth needed; User Interaction (Required) = attacker must time or know about cached content; Scope (Unchanged) = no privilege escalation; Confidentiality (Low impact in CVSS weighting). The 'LOW' rating underrepresents real-world risk for applications that cache sensitive user data, making prioritization a business decision rather than a strictly numerical one.

Frequently asked questions