CVE-2026-61588 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, when a Django `Model` instance is assigned to a public view attribute, djust serialized it to the client with no sensitive-field denylist — sending fields such as `password` (the hash), privilege flags (e.g. `is_staff` / `is_superuser`), tokens, and other PII to the browser. Because exposing model objects to templates is a normal djust pattern, this could leak credentials/PII without the developer realizing the full object crossed the wire. This is fixed in djust 1.0.7. Model serialization applies a secure-by-default sensitive-field denylist (password/hash/token/secret-style fields and known privilege flags are withheld) with an identity-subset fallback. As a workaround, keep `Model` instances on `_private` attributes and expose only the specific fields needed, until patched.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in djust prior to version 1.0.7 represents a critical information disclosure flaw rooted in improper object serialization during server-side rendering operations. As a library designed to provide Phoenix LiveView-style reactive interfaces for Django using Rust-powered performance optimizations, djust facilitates the transmission of model instances from the backend to the frontend client. The core technical failure lies in the absence of a sensitive-field denylist when serializing Django Model instances assigned to public view attributes. In standard development patterns within this framework, developers often expose entire model objects to templates for reactive updates. However, without explicit filtering mechanisms, the serialization process indiscriminately includes all fields present on the model instance, regardless of their sensitivity classification. This architectural oversight results in the transmission of highly confidential data, including password hashes, privilege flags such as is_staff or is_superuser, authentication tokens, and personally identifiable information (PII), directly to the browser environment where they are accessible via client-side inspection tools.
The operational impact of this vulnerability is severe, potentially leading to full account compromise and significant privacy violations. By exposing password hashes to the client side, attackers can attempt offline brute-force or rainbow table attacks against these credentials if they gain access to the rendered HTML source or network traffic. Furthermore, the exposure of privilege flags allows adversaries to map user roles and permissions within the application infrastructure, facilitating targeted privilege escalation attempts. The leakage of authentication tokens and PII further exacerbates the risk by enabling session hijacking and identity theft scenarios. Because this behavior is tied to a common development pattern in djust, many applications may inadvertently leak sensitive data without developer awareness, as the framework does not enforce secure defaults for model serialization out-of-the-box in versions preceding 1.0.7.
This vulnerability aligns with CWE-209: Generation of Error Message Containing Sensitive Information and CWE-359: Exposure of Private Personal Information to an Unauthorized Actor. From a threat modeling perspective, it corresponds to ATT&CK technique T1005: Data from Local System Retrieval, as the attacker extracts sensitive data directly from the application's output stream. The root cause is classified under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, specifically due to improper access control and lack of input validation regarding what data structures are exposed via public interfaces.
To mitigate this risk in unpatched environments, developers should immediately refactor their codebase to adhere to the principle of least privilege by keeping Model instances on private attributes prefixed with underscores rather than exposing them as public view attributes. Instead of passing full model objects, only specific, non-sensitive fields required for rendering or interaction should be explicitly extracted and passed to templates. This manual filtering ensures that sensitive data such as password hashes, tokens, and internal flags remain confined to the server side. For long-term remediation, upgrading djust to version 1.0.7 or later is essential, as this release implements a secure-by-default serialization mechanism. The patched version automatically applies a denylist for known sensitive field types including passwords, secrets, tokens, and privilege indicators, while utilizing an identity-subset fallback strategy that ensures only necessary data is transmitted without manual intervention from the developer.