CVE-2026-61597 in djust
Summary
by MITRE • 09/17/2026
djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, many djust built-in component template tags (`djust.components.templatetags.*`) render a developer/user-supplied URL into an `href` / `action` attribute, HTML-escaping it with `conditional_escape` but never validating the URL scheme. HTML escaping prevents attribute breakout but does not neutralize a `javascript:` URI (which needs no escapable characters), so a URL value of `javascript:alert(document.cookie)` lands verbatim in `<a href="javascript:alert(document.cookie)">` and executes in the victim's session on click. Version 1.0.7 contains a fix. As a workaround, do not pass user-controllable URLs to the affected built-in component tags; pre-validate URL schemes in application code before binding them to component arguments.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in djust versions prior to 1.0.7 represents a classic Cross-Site Scripting (XSS) flaw rooted in insufficient input validation for URI schemes within server-side rendered components. Although the library employs HTML escaping via Django's conditional_escape function, this mitigation is fundamentally inadequate against javascript: URIs because such payloads do not require special characters to break out of their context or bypass standard encoding mechanisms. When a developer passes a user-supplied URL into built-in component template tags, the system correctly escapes standard HTML entities but fails to inspect the scheme portion of the URI. Consequently, if an attacker supplies a value like javascript:alert(document.cookie), it is rendered verbatim within href or action attributes, leading to immediate execution in the victim's browser context upon interaction with the affected element.
From a technical perspective, this flaw aligns with CWE-79, which covers Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The specific mechanism here is often categorized under CWE-80 or more precisely related to improper validation of URI schemes, where the application trusts the input format without verifying that it conforms to safe protocols such as HTTP or HTTPS. In the context of the MITRE ATT&CK framework, this vulnerability facilitates Execution via client-side script injection, allowing an attacker to hijack user sessions, steal sensitive cookies, perform actions on behalf of the victim, or redirect users to malicious sites. The absence of scheme validation means that any input field bound to these component tags becomes a potential vector for persistent or reflected XSS attacks depending on how the data is sourced and stored.
The operational impact of this vulnerability can be severe in applications where user-generated content influences navigation elements. An attacker could craft a link within a comment, profile description, or form submission that triggers when another user clicks it. Since djust provides reactive server-side rendering similar to Phoenix LiveView for Django, the attack surface is broadened by the ease with which dynamic data can be bound to UI components without explicit security checks at the binding layer. This creates a situation where developers might assume that standard template escaping is sufficient protection, overlooking the specific risks associated with URI-based execution contexts. The vulnerability persists until version 1.0.7, indicating that earlier releases lacked any form of protocol whitelisting or blacklist for URL schemes within these helper tags.
To mitigate this risk, immediate action should be taken to upgrade djust to version 1.0.7 or later, where the underlying logic has been corrected to validate URI schemes before rendering them into HTML attributes. For environments that cannot immediately patch due to dependency constraints, a robust workaround involves implementing strict URL scheme validation in application code prior to passing any user-controllable values to the affected component tags. Developers should ensure that only safe protocols such as http and https are permitted, rejecting or sanitizing inputs containing javascript:, data:, vbscript:, or other executable schemes. Additionally, adopting Content Security Policy headers can provide a secondary layer of defense by restricting script execution sources, although this does not replace the need for proper input validation at the application logic level. Regular security audits focusing on how dynamic content is bound to interactive elements are recommended to prevent similar oversights in future development cycles.