CVE-2026-6873

What it actually does

Django’s `HttpRequest.get_signed_cookie()` derived the signing salt by directly concatenating the cookie name and caller-supplied salt. Because concatenation is not injective, two different `(cookie_name, salt)` pairs can produce the same derived salt, allowing a signed cookie created for one logical purpose to validate in another context if an application uses colliding names and salts. The flaw does not generally let an attacker forge arbitrary signed cookies; exploitation requires access to a valid signed cookie from one context and an application design that creates a salt-collision path into a more sensitive context.

Why it matters to the business

Applications that rely on signed cookies for trust decisions may accept a cookie outside its intended use, potentially causing limited authorization, preference, workflow, or state confusion. The practical risk is usually low to moderate because exploitation depends on specific application cookie naming and salt usage, but internet-facing Django applications using signed cookies should still be upgraded to avoid subtle authentication or business-logic bypasses. The issue is not currently in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, reducing immediate mass-exploitation concern.

How an attack unfolds

An attacker first identifies a Django application that uses `get_signed_cookie()` in multiple places with different cookie names and salt arguments. They then look for two contexts where the concatenation of the cookie name and salt is identical, such as one pair where the cookie name contributes a prefix and another where the salt contributes that same prefix. The attacker obtains a legitimately signed cookie from a lower-risk or attacker-accessible context, for example by logging in as a low-privileged user or triggering normal application functionality that sets a signed cookie. They then submit that signed cookie under the colliding cookie name expected by a different code path. If the application’s logic treats the value as meaningful in the second context, Django may validate the signature even though the cookie was originally signed for a different purpose, leading to context confusion or limited privilege/logic bypass.

How to fix it

Upgrade Django to a fixed release: Django 6.0 users should upgrade to 6.0.6 or later, and Django 5.2 users should upgrade to 5.2.15 or later. Unsupported Django branches, including 5.0.x, 4.1.x, and 3.2.x, were not evaluated and may also be affected; migrate those applications to a supported fixed branch rather than relying on unsupported releases. After upgrading, review application code that calls `get_signed_cookie()` with custom salts and ensure cookie names and salt values are clearly separated by design. As a defense-in-depth measure, rotate secrets or invalidate sensitive signed-cookie state if there is concern that cookies were reused across security boundaries. Avoid using signed cookies as the sole source of authorization decisions for sensitive actions.

How to confirm the fix worked

Confirm the installed Django version is 6.0.6 or later for the 6.0 series, or 5.2.15 or later for the 5.2 series. For Python environments, validate with package inventory tooling such as `python -m django --version`, `pip show django`, lockfile review, container image SBOMs, and CI dependency scans. Search application code for `get_signed_cookie(` and review every call that passes a `salt` argument. Verify that no security-sensitive logic accepts signed-cookie values from contexts where a lower-privileged or unrelated cookie could collide. Regression tests should include cases with ambiguous `(cookie name, salt)` concatenations and confirm cookies signed for one context are rejected in another after the upgrade.

Typical attack path

1. Discover or infer that the target application is built on an affected Django version.
2. Identify signed-cookie usage where multiple cookie names and custom salt values are used with `get_signed_cookie()`.
3. Find distinct `(cookie name, salt)` pairs that produce the same concatenated salt string.
4. Obtain a valid signed cookie from an attacker-accessible or lower-privilege context.
5. Replay that cookie using the colliding cookie name expected by a more sensitive code path.
6. Trigger application functionality that trusts the replayed signed cookie value outside its original context.

How to detect it

There are no universal network or host indicators for this issue because successful exploitation looks like normal HTTP traffic carrying validly signed cookies. To assess possible prior exploitation, review application source code first to identify endpoints that call `get_signed_cookie()` with custom salts, then examine web access logs, application logs, WAF logs, and reverse-proxy logs for requests to those endpoints containing unexpected cookie names, duplicate or similarly prefixed cookie names, or signed-cookie values reused across different cookie names. Pay particular attention to authentication, authorization, onboarding, invitation, approval, and state-changing workflows. If application logs include cookie validation failures, compare failures and successes around the same client IP, account, session, user agent, and endpoint. For forensics, collect historical request headers where available, session/audit logs, user action logs, and application exceptions around signed-cookie parsing. Because the vulnerability permits context confusion rather than code execution, evidence is more likely to appear as anomalous business actions, unexpected state transitions, or unusual cookie usage than as malware, shell commands, or new files.

What your security team should do

• Inventory all Django applications and prioritize internet-facing systems and applications that use signed cookies for authentication, authorization, workflow state, password-reset-like flows, invitations, approvals, or financial/business decisions.
• Upgrade affected supported versions to Django 6.0.6+ or 5.2.15+ as applicable; migrate unsupported Django branches to a supported fixed release.
• Search codebases for `get_signed_cookie(` and custom `salt=` usage; review whether any cookie names and salts could collide by concatenation.
• Invalidate or rotate sensitive signed cookies where cookie reuse could have crossed trust boundaries.
• Add automated dependency checks to block Django versions earlier than 6.0.6 in the 6.0 line and earlier than 5.2.15 in the 5.2 line.
• Review access logs for unusual cookie-name manipulation or repeated requests involving similarly named signed cookies, especially around authentication or state-changing endpoints.