Django CVE-2026-35193

Exploitation requires three concurrent conditions: (1) django.middleware.cache.UpdateCacheMiddleware must be present and active in the Django application's middleware configuration; (2) a shared caching intermediary - reverse proxy, CDN, or similar - must exist between end users and the Django application and must cache responses based on URL without independently enforcing Vary: Authorization; and (3) a legitimate authenticated user must have made a request to the target URL within the cache TTL window, warming the cache entry, before the unauthenticated attacker's request arrives. The authenticated request must not carry an explicit Cache-Control: public header, which is the normal case for authenticated endpoints. The CVSS AT:P and UI:P flags directly encode these prerequisites. Exploitation is not possible against applications that do not use UpdateCacheMiddleware, serve only public content at affected URLs, apply Cache-Control: no-store or private on authenticated responses, or lack a shared caching layer between the application and clients.

The CVSS 4.0 score of 2.3 (Low) accurately reflects a real but narrowly scoped threat. Decomposing the vector: AV:N confirms network exploitability with no proximity requirement; AC:L indicates the attack mechanics themselves are straightforward; AT:P (Attack Requirements: Present) is the key limiting factor - a specific caching topology must exist; PR:N confirms no attacker privileges are needed; UI:P (User Interaction: Passive) means a legitimate authenticated user must first warm the cache entry. Impact is bounded at VC:L with no integrity or availability exposure. EPSS data was not provided in available intelligence, preventing probability-of-exploitation quantification. This CVE is not listed in the CISA KEV catalog and no public proof-of-concept exploit code has been identified, consistent with the low severity rating. The practical risk is meaningful specifically for deployments combining Django's cache middleware with shared reverse proxy or CDN infrastructure that respects Vary headers imperfectly or not at all - a common production pattern. Organizations not using UpdateCacheMiddleware, or those applying Cache-Control: no-store or private on authenticated endpoints, face no exposure. The low CVSS score is justified and not in conflict with the description; this is not a case of understated severity.

An authenticated user requests /api/account/settings/ through a production deployment using Django's UpdateCacheMiddleware behind a shared Nginx or CDN cache. Because Django omits Authorization from the Vary header, the cache stores the authenticated response keyed only on the URL. An unauthenticated attacker subsequently requests the same URL and receives the cached authenticated response containing the victim's private account data. No public exploit code has been identified; successfully executing this attack requires the attacker to know or guess a URL where an authenticated response has been recently cached.