Django ships 6.0.6 and 5.2.15 with five low-severity CVE fixes

The Django team issued security releases 6.0.6 and 5.2.15 on 2026-06-03, addressing five CVEs all rated low severity by Django’s security policy. The release is a routine quarterly patch in shape, but the issue list is unusually surface-broad: one cookie signing bug, one STARTTLS fallback, and three separate Cache-Control or Vary header behaviors that combine to make a non-trivial portion of cached responses suspect for apps running custom caching middleware.

What shipped

CVE-2026-6873 covers signed-cookie salt derivation in get_signed_cookie(). The previous implementation derived the salt by concatenating the cookie name and the salt argument, which meant distinct name and salt pairs could collide on the same concatenation and accept cookies signed in a different context. Cookies now use an unambiguous salt derivation. Cookies signed by older Django versions remain accepted through Django 7.0 for backwards compatibility.

CVE-2026-7666 covers an unencrypted email path through STARTTLS. With EMAIL_USE_TLS enabled, a failed STARTTLS handshake could leave a partially-initialized SMTP connection that was subsequently reused for sending email without encryption. The path mattered specifically for callers with fail_silently=True, which includes send_mail() and BrokenLinkEmailsMiddleware among others. EMAIL_USE_SSL configurations are not affected. The fix tears down the connection rather than reusing the partial state.

The remaining three CVEs all live in the cache layer. CVE-2026-8404 patches UpdateCacheMiddleware and cache_page to recognize mixed-case Cache-Control directives (the bug surfaced when apps or upstream services emitted Private instead of lowercase private, which the middleware then ignored). CVE-2026-35193 adds a missing Vary: Authorization header so requests bearing an Authorization header are not cached as if they were anonymous. CVE-2026-48587 patches whitespace handling in Vary header values, which was preventing wildcards from being recognized when the header arrived with leading or trailing whitespace.

The cookie salt derivation backwards-compatibility window through Django 7.0 is the one operational detail worth flagging: apps relying on the legacy salt scheme have a known sunset rather than an indefinite reprieve.

Where this lands in the market

Django’s security release cadence in 2026 has been heavier than the 2025 baseline. The April and May releases (6.0.4 / 5.2.13 / 4.2.30 on 2026-04-07 and 6.0.5 / 5.2.14 on 2026-05-05) both covered single or paired issues. Bundling five low-severity issues into a single release suggests the security team has been triaging a queue, which is the opposite of the more common pattern of high-severity issues forcing a rushed point release. Five low-severity fixes shipped together is, on net, a healthier signal than one critical fix shipped alone.

The cache-layer issue cluster is the part of the release that warrants the most attention from teams running Django behind a CDN or shared-cache reverse proxy. The three Cache-Control and Vary bugs each have the same failure shape: a response that should not have been cached, or that should have been varied on a header, ends up cached and served to the wrong user context. None of the three is remotely exploitable in the classical sense, but each can produce data-exposure surprises in apps where authorization decisions and caching interact at the same middleware layer. Patching is the straightforward fix; the harder operational question is whether any existing cache entries need to be invalidated.

For apps still on the 4.2 LTS line, the absence of a 4.2 patch in this release is the load-bearing detail. 4.2 reaches end of support later in 2026. Teams running 4.2 with custom caching middleware are on a clock for the 5.2 LTS migration.

What’s worth watching

1. CVE-2026-6873 backwards-compatibility cliff. The legacy salt derivation stays accepted through Django 7.0 and then stops. Whether the team holds the timeline or extends it under user pressure is a small but readable signal of how the project is weighing security-hygiene clarity against ecosystem disruption.

2. Cache-layer regression follow-ups. Three cache bugs in a single release is a cluster, not a coincidence. Whether the October security window (the next quarterly slot) carries a fourth cache-related fix would suggest the audit that produced this batch was not exhaustive. A clean October release would suggest the work landed.

3. 4.2 LTS migration tail. Django 4.2 reaches end of support in 2026, and this release is one of the last security windows that skips it. Whether the community produces a credible third-party long-term-support fork for 4.2 (in the way some Python LTS projects have) is the readable signal for how widely the 4.2 line is still deployed.

The follow-up beat lands around 2026-09-02, after the next quarterly Django security window has either confirmed the cache-layer audit is complete or surfaced a regression.

Sources cited

1. Django Weblog: Security releases issued (6.0.6 and 5.2.15) www.djangoproject.com
2. Django Forum thread: Security releases 6.0.6 and 5.2.15 forum.djangoproject.com