CVE-2026-61598 in djust
Summary
by MITRE • 09/16/2026
djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, `djust.mixins.model_binding.ModelBindingMixin` provides a default `update_model` event handler and is part of the LiveView base MRO, so every LiveView exposes it. It `setattr`s a view attribute whose name is client-supplied (`field`), gated only by: reject `_`-prefixed names; reject a 14-entry denylist of framework internals (`FORBIDDEN_MODEL_FIELDS`); optional `allowed_model_fields` which defaults to None = allow all; and `hasattr` existence. As a result, a client can set any public, existing view attribute — not just the fields actually bound with `dj-model=` in the rendered template. The denylist covers framework plumbing but nothing about developer business/authz state, and the allowlist is opt-in (off by default). A developer who binds one `dj-model="search"` input and also keeps `self.account_id` / `self.is_admin` / `self.total_price` as view state does not realize a client can set ALL of them via `{type:event, event:"update_model", params:{field, value}}` over the WebSocket. Type coercion matches the target attribute's type (so `"true"` -> bool True), aiding the attacker. This issue is fixed in djust 1.0.7. As a workaround, set `allowed_model_fields` explicitly on every view using dj-model (or subclassing LiveView) to the minimal list of bindable fields; do not keep authorization/ownership state in public view attributes that share the view with dj-model bindings.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in djust prior to version 1.0.7 represents a critical server-side request forgery and insecure direct object reference flaw rooted in the framework's reactive rendering architecture. Djust is designed to provide Phoenix LiveView-style reactive server-side rendering for Django applications, leveraging Rust for performance optimization. However, the implementation of the ModelBindingMixin introduces a significant security gap by exposing an internal event handler, update_model, which allows client-supplied data to directly modify view instance attributes without sufficient validation or authorization checks. This mixin is part of the LiveView base Method Resolution Order (MRO), meaning that every LiveView component instantiated within the application inherits this behavior automatically unless explicitly overridden. The core technical flaw lies in how the framework processes incoming WebSocket messages containing update_model events. When such an event is received, the server extracts a field name and value from the client parameters and uses Python's setattr function to assign the provided value to the corresponding attribute on the view instance.
The security implications of this design are severe because the validation logic governing which attributes can be modified is insufficiently restrictive by default. The framework attempts to mitigate risk through two primary mechanisms: a denylist of forbidden model fields and an optional allowlist called allowed_model_fields. However, the denylist only prevents modification of specific internal framework plumbing variables prefixed with underscores or listed in FORBIDDEN_MODEL_FIELDS. It does not account for developer-defined business logic attributes such as authentication status, user roles, ownership identifiers, or financial calculations. Furthermore, the allowlist mechanism is opt-in and defaults to None, which effectively disables any restriction on field names beyond those explicitly forbidden. Consequently, an attacker can manipulate any public attribute that exists on the view instance at runtime, provided it passes a simple hasattr check. This creates a scenario where state intended to be server-side only becomes mutable by untrusted client input.
The operational impact of this vulnerability extends far beyond mere data corruption; it enables complete compromise of application logic and authorization controls. An attacker can exploit type coercion features inherent in the framework's handling of incoming parameters. For instance, if an attribute is expected to be a boolean, passing the string "true" will result in the Python value True being assigned. This capability allows attackers to escalate privileges by setting attributes like self.is_admin or self.has_permission to true values derived from simple strings. Similarly, financial integrity can be compromised by altering monetary fields such as self.total_price through type coercion into numeric types. Since these state variables are often used throughout the request lifecycle to determine access control decisions and render appropriate UI elements, their manipulation leads directly to unauthorized data access, privilege escalation, or business logic bypasses. The lack of explicit authorization checks within the update_model handler means that any authenticated user can potentially alter critical application state simply by crafting specific WebSocket payloads.
To mitigate this vulnerability, developers must immediately upgrade djust to version 1.0.7 or later, where these issues have been addressed in subsequent releases. For applications unable to upgrade instantly, a robust workaround involves explicitly defining the allowed_model_fields attribute on every LiveView class that utilizes dj-model bindings. This allowlist should contain only the specific model fields intended for client-side updates, effectively restricting the setattr operation to safe, predefined attributes and preventing access to arbitrary view state. Additionally, developers should refactor their codebase to avoid storing sensitive authorization or ownership data in public instance variables of views that are exposed via WebSocket connections. Instead, such critical state should be managed through secure session storage or server-only context objects that are not directly accessible via the reactive binding mechanism. Adhering to these practices ensures that client interactions remain confined to their intended scope and do not inadvertently modify internal application logic.