CVE-2026-61598 PUBLISHED

Client mass-assignment of arbitrary view attributes via the default dj-model update_model handler

Assigner: GitHub_M
Reserved: 10.07.2026 Published: 16.09.2026 Updated: 16.09.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 setattrs 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.

Metrics

CVSS Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
CVSS Score: 7.1

Product Status

Vendor djust-org
Product djust
Versions
  • Version < 1.0.7 is affected

References

Problem Types

  • CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes CWE