The vulnerability in djust arises because the context safety channel is keyed by variable name rather than by value. When a template rebinding occurs (e.g., {% with p=user_input %}), the safety grant associated with the original safe value is incorrectly inherited by the new, potentially unsafe value. This leads to XSS when the template outputs attacker-controlled input marked as safe. Eight distinct binding shapes are affected, including rebinding in {% with %}, loop variables in {% for %}, tuple unpacking, and includes with context overrides. The fix in 1.1.2 changes the behavior so that a bind replaces the safety grant rather than inheriting it, preventing unsafe values from being treated as safe. Some over-escaping issues remain and are tracked for 1.2.0 but do not cause leaks.

This vulnerability allows stored or reflected XSS in any djust application that uses mark_safe (or equivalent safety grants) combined with templates that rebind those safe names to attacker-controlled input. Exploitation requires no unusual template constructs and can lead to execution of arbitrary JavaScript in the context of the vulnerable application, potentially compromising user sessions or data.

A fix is available in djust version 1.1.2 and later. Users should upgrade to at least version 1.1.2 to remediate this vulnerability. Until upgrading, avoid reusing context variable names for both mark_safe'd content and untrusted input, and avoid rebinding such names in template constructs like {% with %}, {% for %}, {% include … with %}, or assign tags.