Django EUVD-2026-34086

Exploitation requires three concurrent conditions: (1) the target Django application must call django.http.HttpRequest.get_signed_cookie in at least two distinct code paths using (name, salt) pairs whose concatenations are identical - a non-default, application-specific coincidence; (2) the attacker must already possess a valid signed cookie issued by the application for one of those contexts, requiring at minimum low-privilege access (PR:L per CVSS vector); and (3) the attacker must be able to submit that cookie to the second context's endpoint. Exploitation is limited to reading data accessible via the misused cookie context (VC:L), not arbitrary code execution. Standard Django deployments using get_signed_cookie with unique, non-colliding (name, salt) pairs are not exploitable. The AT:P element of the CVSS vector explicitly flags that the attack requires the presence of a specific, exploitable target configuration.

The CVSS 4.0 base score of 2.3 accurately reflects the low real-world risk. The vector AV:N/AC:L/AT:P/PR:L/UI:N breaks down as: network-reachable (AV:N), low complexity once a collision pair is identified (AC:L), but critically requiring the presence of a vulnerable target configuration (AT:P) - specifically, an application must have two code paths each calling get_signed_cookie with (name, salt) pairs that collide under concatenation. This is a non-trivial prerequisite. Additionally, PR:L indicates the attacker must already possess a legitimately issued signed cookie from one context before attempting to replay it in the colliding context. Impact is limited to VC:L (low confidentiality breach on the vulnerable system), with no integrity or availability impact. No EPSS data was provided; given the low CVSS, narrow preconditions, and absence from CISA KEV, probabilistic exploitation at scale is unlikely. No public exploit identified at time of analysis. This is a real but low-priority issue unless an application is specifically identified to have colliding (name, salt) pairs in its cookie-signing logic.

An attacker who holds a legitimately issued signed cookie from one application endpoint - for example, a low-privilege session token named 'user_pref' signed with salt 'sett' - identifies that another endpoint calls get_signed_cookie with name 'user' and salt 'prefs_ett', producing the same concatenated salt string 'user_prefs_ett' in both cases. The attacker presents their original cookie to the second endpoint, where it passes signature verification despite being issued for a different context, potentially exposing data or functionality intended only for that second context. No public exploit code has been identified at time of analysis.