Summary
djust: Client mass-assignment of arbitrary view attributes via the default dj-model update_model handler
Advisory details
Impact
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.
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.
Severity High for apps that hold authorization/ownership/business state in public view attributes (the normal djust pattern) -> state tampering / IDOR / authz-flag manipulation; Low otherwise. Default-on across every LiveView. For a public (no-login) view an anonymous client can mass-assign; for an authenticated view a logged-in user can tamper their own session's view state (the IDOR/authz vector when downstream handlers act on it without re-authorizing).
Reproduced: a view with account_id/is_admin/total_price (none bound with dj-model) had all three set via update_model calls.
Patches
Restrict the default handler to fields actually exposed via dj-model=: have the template renderer record the bound-field set per render and reject any field outside it (preferred, secure + zero-config); or make allowed_model_fields fail-closed (required). Keep FORBIDDEN_MODEL_FIELDS only as defense-in-depth. Add a regression that a non-dj-model public attribute (e.g. is_admin) is rejected while a bound field still updates.
Workarounds
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.
References
Reproducer + finding writeup retained privately by the maintainer.
References
Related vulnerabilities
All Supply chain →- CRITICALCVE-2026-105863
Payload authentication token field handling issue
- HIGHCVE-2026-106100
Payload: Field-level write access bypass in Payload on MongoDB
- MEDIUMCVE-2026-103918
@orpc/zod: Prototype injection in smart coercion
- MEDIUMCVE-2026-83557
jackson-databind: Comparable missing from DefaultBaseTypeLimitingValidator's unsafe base types (incomplete PolymorphicTypeValidator denylist)
- MEDIUMCVE-2026-61834
scim-patch: Mutation of Inherited Built-in Method Objects
- HIGHCVE-2026-76086
Formie: Integration form-settings action allows SSRF and exfiltration of stored integration credentials