Django 6.0.7 and 5.2.16: Cache Poisoning Patch — Upgrade Now

Django dropped security releases on July 7, 2026. Versions 6.0.7 and 5.2.16 patch three CVEs, one of which hits a configuration that most production Django apps share: caching middleware running alongside user authentication on a shared cache. If that’s you, a session cookie can end up stored in your cache and served to the wrong user. Run the upgrade. Today.

The Cache Middleware Bug Is the One That Matters

CVE-2026-48588 lives in UpdateCacheMiddleware and the @cache_page decorator. The protection against caching responses with cookies was supposed to fire whenever a response set a cookie while varying on Cookie. It didn’t. It only fired when the incoming request had no cookies at all.

Here’s why that’s almost always bypassed: Django’s own CSRF middleware sets a csrftoken cookie. If a user visits your site — even without being logged in — they pick up a CSRF token. From that point forward, every request they make carries a cookie. The guard never fires again for that user. A login response that issues a sessionid cookie can now be stored in your shared Memcached or Redis cache.

The next person who hits that URL gets the cached response — including the Set-Cookie: sessionid=... header pointing to someone else’s session. This is a textbook web cache deception scenario, and the vector that makes Django’s own release announcement worth reading in full.

Django calls this “low” severity because it requires a specific configuration to be exploitable. That configuration is: caching middleware, plus a shared cache backend, plus user sessions. That’s a standard Django stack for any authenticated web app doing performance caching. “Low” is underselling it.

Patch Now — It Takes One Command

No workarounds. No config changes. Just upgrade.

# Django 6.0.x
pip install "django>=6.0.7"

# Django 5.2.x
pip install "django>=5.2.16"

# Verify your version
python -c "import django; print(django.__version__)"

If you’re on Django 4.2: that branch is EOL. No security patch is coming. Consult the Django 6.0.7 release notes for migration guidance and upgrade to 5.2 LTS or 6.0 now.

Are You Vulnerable? Audit Your Settings

You’re in the vulnerable configuration if all three of these are true:

• UpdateCacheMiddleware is in your MIDDLEWARE list, or you use @cache_page
• Your cache backend is shared (Memcached or Redis without per-user key namespacing)
• Your app has user authentication and sessions

Check your settings.py for this pattern:

MIDDLEWARE = [
    'django.middleware.cache.UpdateCacheMiddleware',      # present?
    'django.middleware.csrf.CsrfViewMiddleware',          # almost certainly yes
    'django.contrib.sessions.middleware.SessionMiddleware',
    ...
    'django.middleware.cache.FetchFromCacheMiddleware',   # present?
]

If you only use per-view cache with private backends, or have no caching at all, you’re not affected. But if you have the full stack above — and many production Django apps do — patch before someone else finds your cache.

The Other Two CVEs

CVE-2026-53878 fixes a header injection path in DomainNameValidator. It accepted newlines in domain name inputs, enabling HTTP response splitting if those values were passed directly into response headers. The blast radius is limited — Django’s own CharField strips newlines, so built-in form fields are safe. If you use DomainNameValidator in custom validator code outside form field context, review it. The fix commit shows exactly what changed.

CVE-2026-53877 addresses a heap buffer over-read in GDALRaster when instantiated with raw bytes. This is GeoDjango territory — if you’re not doing geospatial work, it doesn’t touch you.

Subscribe to Security Alerts

Django’s security team maintains an RSS feed specifically for security releases. Add it to your feed reader now: https://www.djangoproject.com/rss/weblog/security/. You can also audit your current deployment configuration with:

python manage.py check --deploy

It catches common misconfigurations beyond what these CVEs address — missing SECURE_SSL_REDIRECT, unconfigured ALLOWED_HOSTS, and similar issues that compound the risk if your cache is misconfigured. Browse the full Django security issue archive to understand the historical pattern of cache-related vulnerabilities in the framework.

Three CVEs, one command, done. The cache middleware bug in particular is a session leak waiting to happen on any standard authenticated Django app with caching enabled. Django 6.0.7 and 5.2.16 are the right versions to be on right now.