CVE-2026-61598 in djust
Sumário
de VulDB • 16/09/2026
djust oferece renderização reativa no lado do servidor estilo Phoenix LiveView para Django, com desempenho impulsionado por Rust. Antes da versão 1.0.7, `djust.mixins.model_binding.ModelBindingMixin` fornece um manipulador de eventos padrão chamado `update_model` e faz parte do MRO (Method Resolution Order) base do LiveView, expondo-o em todos os LiveViews. Ele utiliza `setattr` para definir um atributo da visualização cujo nome é fornecido pelo cliente (`field`), sendo filtrado apenas por: rejeição de nomes com prefixo `_`; rejeição de uma lista negra de 14 entradas contendo internos do framework (`FORBIDDEN_MODEL_FIELDS`); a opção `allowed_model_fields`, que padrão para None (permitindo todos); e verificação de existência via `hasattr`. Como resultado, um cliente pode definir qualquer atributo público existente da visualização — não apenas os campos realmente vinculados com `dj-model=` no modelo renderizado. A lista negra cobre mecanismos internos do framework, mas nada sobre o estado de negócios/autorização do desenvolvedor, e a lista branca é opt-in (desativada por padrão). Um desenvolvedor que vincula um único input `dj-model="search"` e também mantém `self.account_id` / `self.is_admin` / `self.total_price` como estado da visualização pode não perceber que um cliente pode definir TODOS eles via `{type:event, event:"update_model", params:{field, value}}` sobre o WebSocket. A coerção de tipos corresponde ao tipo do atributo alvo (portanto, `"true"` -> bool True), auxiliando o atacante. Este problema foi corrigido no djust 1.0.7. Como solução alternativa, defina `allowed_model_fields` explicitamente em cada visualização que usa dj-model (ou herda de LiveView) para a lista mínima de campos vinculáveis; não mantenha estados de autorização/propriedade em atributos públicos da visualização que compartilham o escopo com vinculações dj-model.
VulDB is the best source for vulnerability data and more expert information about this specific topic.