CVE-2026-6873: Django Signed Cookie Salt Collision Vulnerability

Technical summary

The vulnerability exists in Django's `django.http.HttpRequest.get_signed_cookie` method, which derives a salt by simple string concatenation of the cookie name and a salt argument. Because concatenation is non-injective, distinct (name, salt) pairs can produce identical derivation outputs. For example, (name='a', salt='b') and (name='ab', salt='') both yield 'ab'. An attacker with prior authentication can craft requests using a signed cookie from one context in another context where the name/salt collision produces the same HMAC signature, bypassing the intended per-context binding. The flaw is categorized as CWE-347 (Improper Verification of Cryptographic Signature).

Business impact

Organizations relying on Django's signed cookies for feature-level or per-request separation of privileges may face unauthorized lateral movement between features by authenticated users. The impact is limited by the requirement for prior authentication and the attacker's need to identify exploitable name/salt collisions, but it does weaken a security mechanism intended to isolate cookie validity to specific contexts. For applications with complex privilege or session boundaries, this could enable privilege escalation or unauthorized data access.

Affected systems

Django 6.0 before version 6.0.6 and Django 5.2 before version 5.2.15 are confirmed affected. The vendor notes that earlier, unsupported series (5.0.x, 4.1.x, 3.2.x, and potentially others) were not evaluated and may also contain the flaw. Organizations running these versions should audit their cookie handling, particularly those using signed cookies for context-specific authorization.

Exploitability

Exploitation requires the attacker to already be authenticated to the Django application (PR:L in CVSS vector), making this a post-authentication attack. The attacker must also identify or deliberately construct (name, salt) pairs that collide, which requires some trial or knowledge of the application's cookie naming scheme. No public exploit code is known, and the vulnerability does not appear on CISA's Known Exploited Vulnerabilities list. The low CVSS score (3.1) reflects these barriers.

Remediation

Upgrade Django 6.0 to version 6.0.6 or later, or upgrade Django 5.2 to version 5.2.15 or later. For unsupported versions (5.0.x, 4.1.x, 3.2.x), monitor vendor advisories or consider upgrading to a supported release. Review custom code that may implement similar salt derivation patterns, as the same non-injective concatenation logic may exist elsewhere.

Patch guidance

Django 6.0.6 and Django 5.2.15 are the patched versions addressing this issue. These updates modify the salt derivation mechanism to ensure proper separation and prevent collisions. Verify against the Django security advisory or release notes for confirmation of patch content. Plan upgrades during normal maintenance windows; the low severity does not necessitate emergency patching, but should be included in regular security updates.

Detection guidance

Monitor for suspicious patterns of cookie reuse across different request contexts by analyzing application logs for the same signed cookie value appearing in unexpected feature or privilege boundaries. Consider instrumenting `get_signed_cookie` calls to log the (name, salt) pairs being validated. Intrusion detection systems may flag requests that attempt to reuse cookies outside their intended context, though detection depends on understanding your application's legitimate cookie boundaries. No public YARA or signature-based detection is needed for this cryptographic weakness alone.

Why prioritize this

This vulnerability is a low-severity cryptographic bypass affecting authenticated users. Prioritize it below critical authentication or unauthenticated remote code execution flaws, but include it in your routine patching cycle. Organizations with multi-tenant or complex privilege models using Django's signed cookies should accelerate remediation. Those not relying on signed cookies for authorization boundaries can defer patching without elevated risk.

Risk score, explained

CVSS 3.1 score of 3.1 (LOW) reflects: (1) requirement for prior authentication (PR:L), (2) high attack complexity requiring collision discovery (AC:H), (3) low confidentiality impact limited to unauthorized data access within an already-authenticated session (C:L), and (4) no integrity or availability impact. The score appropriately downgrades severity because exploitation requires an already-trusted user to invest effort in identifying collisions.

Frequently asked questions