GHSA-XJW9-38CR-6372: Cross-Site Scripting via Stale Safe-Key Inheritance in djust Template Shadowing

The djust templating engine is a high-performance, reactive server-side rendering library designed for Django applications. It uses a Rust-powered backend implementation (comprising the djust_core and djust_templates crates) to compile and render templates quickly. To maintain compatibility with Django's safety markings, djust passes information about which variables have been marked as safe across the PyO3 foreign function interface boundary.

However, the mechanism used to track context safety properties was designed to key safety settings by variable name rather than using individual object instances. When standard Django templates wrap strings in SafeData subclasses, the djust engine registers the corresponding variable paths inside a flat security lookup collection. If an outer variable is marked safe, any inner shadow scope that rebinds that same variable name will inherit the safe designation.

This architectural design flaw exposes a cross-site scripting attack surface. When templates employ common shadowing structures such as nested loop scopes or with blocks, the safety metadata remains pinned to the key. This allows untrusted user inputs bound to the shadowed variable name to bypass escaping and render raw HTML directly to the client browser.

This vulnerability affects all releases of djust from version 1.0.0 up to and including version 1.1.1. The issue has been addressed in version 1.1.2 by introducing active safety-key revocation during scope binding operations.

To understand the root cause of the vulnerability, we must examine the context management architecture in crates/djust_core/src/context.rs. The Context struct tracks safe variables using a HashSet containing String keys named safe_keys. When a Python string is marked safe via Django's mark_safe, its dictionary path is added to this set.

When rendering template nodes, the engine determines whether to escape a value by calling Context::is_safe with the variable's key path. If the path exists in safe_keys, the engine skips HTML sanitization. The vulnerability occurs because the engine handles variable rebinding by overwriting the context value map while leaving the safe_keys set unchanged.

This security bypass occurs across eight template binding structures. These include with assignments, for loops, tuple unpacking in loop iterations, template inclusions using with blocks, and custom assign tags. In each case, the safety grant associated with the key survives the shadowing operation, causing the new, untrusted value to render without escaping.

Before the patch, the template renderer in crates/djust_templates/src/renderer.rs updated variable values in shadow scopes using Context::set, which did not affect the safe_keys HashSet:

// Vulnerable update path in crates/djust_templates/src/renderer.rs
new_context.set(var_name.clone(), value);

To resolve this issue, the maintainers implemented Context::bind in crates/djust_core/src/context.rs. This method revokes the safety grant of the shadowed variable and any of its dotted-path descendants before binding the new value:

impl Context {
    // Safe binding method introduced in v1.1.2
    pub fn bind(&mut self, name: String, value: Value) {
        self.revoke_safe_subtree(&name);
        self.set(name, value);
    }
 
    // Revokes safety designations for the key and all nested paths
    pub fn revoke_safe_subtree(&mut self, key: &str) {
        if self.safe_keys.is_empty() {
            return;
        }
        self.safe_keys.remove(key);
        let prefix = format!("{}.", key);
        self.safe_keys.retain(|k| !k.starts_with(&prefix));
    }
}

For loop constructs ({% for %}), calling revoke_safe_subtree inside the loop body would degrade performance to O(N * M) complexity, where N is the loop count and M is the size of safe_keys. To avoid this, the fix hoists the revocation step out of the loop body:

// Optimized loop initialization in crates/djust_templates/src/renderer.rs
let mut ctx = context.clone();
for var_name in var_names {
    ctx.revoke_safe_subtree(var_name);
}

This optimization strips safe keys from the context once before starting the loop iterations, maintaining template rendering speed while preventing safe-key inheritance.

An attacker can exploit this vulnerability by targeting template components that shadow variables that are marked safe in the parent view context. This requires the application to expose an endpoint where input can be passed into a shadowed template variable.

Consider an application where a Django view marks a variable named 'p' as safe to output trusted HTML. If the associated template subsequently binds user input to 'p' within an inner block, the input inherits the safe marking of the outer variable:

{% with p=request.GET.q %}
  <div class="user-container">
    {{ p }}
  </div>
{% endwith %}

If an attacker targets this endpoint with a payload containing malicious HTML or JavaScript, the template engine skips escaping and renders the payload directly into the HTTP response. When the response is loaded, the victim's browser processes and executes the injected script:

<div class="user-container">
  <img src=x onerror=alert(document.domain)>
</div>

This allows the attacker to execute arbitrary scripts in the victim's browser, enabling session hijacking, CSRF bypass, and unauthorized actions within the application.

This vulnerability poses a significant risk to applications using the djust template library. Based on CVSS v3.1 metrics, the security impact is assessed at a High severity level with a score of 8.2 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).

The attack vector is network-based (AV:N) and requires low complexity (AC:L) to execute. It requires no authentication privileges (PR:N) but does require interaction from a victim (UI:R), such as clicking a link containing the exploit payload. The impact scope is changed (S:C) because the vulnerability allows code execution to migrate from the server's templating context to the victim's browser session.

Successful exploitation can result in a high loss of confidentiality (C:H) as attackers can steal session tokens and sensitive data. It also causes a low loss of integrity (I:L) because attackers can modify the structure of the rendered web page. The vulnerability is classified under CWE-79 (Improper Neutralization of Input During Web Page Generation).

The recommended remediation is upgrading the djust library to version 1.1.2 or higher. This release integrates safe context bindings across all template rendering pathways, ensuring safety grants do not persist past shadow scopes.

If you cannot update the library immediately, you can mitigate the vulnerability by reviewing your templates. Ensure that no variable names marked safe in your Django views are shadowed inside with, for, or include blocks. Using unique, non-overlapping names for safe-marked variables and user-controlled variables will prevent safe-key inheritance.

Additionally, you can deploy Web Application Firewall rules to block common XSS payloads at the network boundary. Rules should target script tags, execution hooks like onerror=, and JavaScript protocols in URL parameters. However, these signatures should be used as a defense-in-depth measure and not as a replacement for the library update.