CVE-2026-61598: CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes in djust-org djust
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.
AI Analysis
Technical Summary
The vulnerability in djust versions before 1.0.7 arises from the ModelBindingMixin's update_model event handler, which uses setattr to modify view attributes named by the client. Filtering is limited to rejecting underscore-prefixed names and a small denylist of framework internals, with an optional allowlist that defaults to allowing all public attributes. Consequently, clients can set any public attribute, including sensitive business or authorization state, via WebSocket events. Type coercion matches the attribute's type, facilitating exploitation. The issue is resolved by explicitly setting allowed_model_fields or upgrading to version 1.0.7 or later.
Potential Impact
An attacker with low privileges can remotely modify arbitrary public attributes of a LiveView instance, including sensitive authorization or business logic state, potentially leading to unauthorized actions or privilege escalation within the application. This undermines the integrity of server-side state management in djust applications.
Mitigation Recommendations
Upgrade to djust version 1.0.7 or later, where this issue is fixed. As a workaround, explicitly set the allowed_model_fields attribute on every view using dj-model or subclassing LiveView to restrict which fields can be updated by clients. Avoid storing sensitive authorization or ownership state in public view attributes accessible via dj-model bindings.
CVE-2026-61598: CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes in djust-org djust
Description
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.
CVSS v4.0
Score 7.1high
Affected software
djust-org
djust
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in djust versions before 1.0.7 arises from the ModelBindingMixin's update_model event handler, which uses setattr to modify view attributes named by the client. Filtering is limited to rejecting underscore-prefixed names and a small denylist of framework internals, with an optional allowlist that defaults to allowing all public attributes. Consequently, clients can set any public attribute, including sensitive business or authorization state, via WebSocket events. Type coercion matches the attribute's type, facilitating exploitation. The issue is resolved by explicitly setting allowed_model_fields or upgrading to version 1.0.7 or later.
Potential Impact
An attacker with low privileges can remotely modify arbitrary public attributes of a LiveView instance, including sensitive authorization or business logic state, potentially leading to unauthorized actions or privilege escalation within the application. This undermines the integrity of server-side state management in djust applications.
Mitigation Recommendations
Upgrade to djust version 1.0.7 or later, where this issue is fixed. As a workaround, explicitly set the allowed_model_fields attribute on every view using dj-model or subclassing LiveView to restrict which fields can be updated by clients. Avoid storing sensitive authorization or ownership state in public view attributes accessible via dj-model bindings.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-07-10T17:12:17.238Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6aaaa16f55bf5e2cf5b35d44
Added to database: 09/16/2026, 14:02:23 UTC
Last enriched: 09/16/2026, 14:16:53 UTC
Last updated: 09/17/2026, 03:39:32 UTC
Views: 9
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.