CVE-2026-61598

djust zapewnia reaktywne renderowanie po stronie serwera w stylu Phoenix LiveView dla Django z wydajnością opartą na Rust. Przed wersją 1.0.7 `djust.mixins.model_binding.ModelBindingMixin` zapewnia domyślną procedurę obsługi zdarzeń `update_model` i jest częścią podstawowego MRO LiveView, więc każdy LiveView go udostępnia. Jest to `setattr` atrybut widoku, którego nazwa jest dostarczana przez klienta (`pole`), bramkowany tylko przez: odrzucanie nazw z przedrostkiem `_`; odrzuć 14-wpisową listę odrzuconych elementów wewnętrznych frameworka (`FORBIDDEN_MODEL_FIELDS`); opcjonalne `allowed_model_fields`, które domyślnie ma wartość Brak = zezwalaj wszystkim; i „hasattr” istnienie. W rezultacie klient może ustawić dowolny publiczny, istniejący atrybut widoku — nie tylko pola faktycznie powiązane z `dj-model=` w renderowanym szablonie. Lista odrzuconych obejmuje instalację frameworka, ale nie dotyczy stanu firmy/autoryzacji programisty, a lista dozwolonych jest opcjonalna (domyślnie wyłączona). Programista, który wiąże jedno wejście `dj-model="search"` i zachowuje także `self.account_id` / `self.is_admin` / `self.total_price` jako stan widoku, nie zdaje sobie sprawy, że klient może ustawić je WSZYSTKIE poprzez `{type:event, event:"update_model", params:{field, value}}` przez WebSocket. Typ przymusu odpowiada typowi atrybutu celu (czyli `"true"` -> bool True), pomagając atakującemu. Ten problem został rozwiązany w wersji djust 1.0.7. Jako obejście, ustaw jawnie `allowed_model_fields` w każdym widoku, używając dj-model (lub podklasy LiveView) na minimalną listę możliwych do powiązania pól; nie przechowuj stanu autoryzacji/własności w atrybutach widoku publicznego, które współdzielą widok z powiązaniami dj-model.