Is there a patch available for CVE-2026-48588?

Yes, a patch is available for CVE-2026-48588. Update the affected software to the latest version immediately.

Django CVE-2026-48588

Q: What is the CVSS score of CVE-2026-48588?

CVE-2026-48588 has a CVSS 4.0 base score of 2.3 (Low). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

EUVD-2026-42043 LOW

Use of Cache Containing Sensitive Information (CWE-524)

2026-07-07 DSF

GHSA-3h9f-r86x-qvjx

Python Information Disclosure Django

2.3

CVSS 4.0 · Vendor: DSF

Severity by source

Vendor (DSF) PRIMARY

2.3 MEDIUM

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

3.1 LOW

AC:H reflects the three-way prerequisite (caching middleware, cookie-Vary responses, shared backend); UI:R because a victim must populate the cache first; C:L for partial private data disclosure only.

3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (DSF).

CVSS VectorVendor: DSF

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

Patch available

Jul 07, 2026 - 16:01 EUVD

Analysis Generated

Jul 07, 2026 - 15:24 vuln.today

Severity Changed

Jul 07, 2026 - 15:22 NVD

MEDIUM LOW

CVSS changed

Jul 07, 2026 - 15:22 NVD

4.2 (MEDIUM) 2.3 (LOW)

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

12 pypi packages depend on django (12 direct, 0 indirect)

Ecosystem-wide dependent count for version 5.2.

DescriptionCVE.org

An issue was discovered in Django 6.0 before 6.0.7 and 5.2 before 5.2.16. UpdateCacheMiddleware and the cache_page() decorator cache responses that vary on cookies when the incoming request carries unrelated cookies, which allows remote attackers to read private data from the shared cache. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Chris Whyland for reporting this issue.

AnalysisAI

Cache poisoning in Django's UpdateCacheMiddleware and cache_page() decorator exposes private user data to unauthenticated remote attackers by incorrectly serving cached responses across different cookie contexts. Versions 6.0 before 6.0.7 and 5.2 before 5.2.16 are confirmed affected; older unsupported branches (5.0.x, 4.1.x, 3.2.x) were not evaluated but may share the flaw. No public exploit or CISA KEV listing exists at time of analysis, and the low CVSS 4.0 score of 2.3 reflects meaningful preconditions, though the data-disclosure consequence for applications serving personalized, cookie-gated content through a shared cache is concrete.

Technical ContextAI

Django's caching framework uses the Vary header to differentiate cached entries by cookie values (CWE-524: Use of Cache-Containing Sensitive Information). When a response is decorated with cache_page() or processed by UpdateCacheMiddleware and it varies on cookies, the framework is supposed to serve only requests whose cookie set exactly matches the cache key. The defect causes responses to be cached or retrieved even when the incoming request carries unrelated cookies that do not influence the response content. This means a request with an extraneous, innocuous cookie can collide with or retrieve a cache entry that was originally populated for a different user or session, bypassing the intended cookie-based cache segmentation. The CPE cpe:2.3:a:djangoproject:django:*:*:*:*:*:*:*:* covers the full Django project; the vulnerability is purely a logic error in the Python caching middleware layer, not in any C extension or database driver.

RemediationAI

The primary fix is upgrading to Django 6.0.7 or Django 5.2.16, both released on 2026-07-07 per the official advisory at https://www.djangoproject.com/weblog/2026/jul/07/security-releases/. For deployments that cannot immediately upgrade, the most effective compensating control is to disable caching for any view that produces cookie-personalized or user-private responses by removing cache_page() decorators and exempting those views from UpdateCacheMiddleware using the never_cache decorator, at the cost of losing caching benefits on those endpoints. Alternatively, switching from a shared cache backend to a per-user or per-session cache backend eliminates the cross-user collision risk. Deployments on unsupported branches (5.0.x, 4.1.x, 3.2.x) should treat this as a forcing function to upgrade to a supported series, as no patches will be issued for those versions.