CVE-2026-61598 in djust
Resumen
por VulDB • 2026-09-16
djust proporciona renderizado reactivo en el lado del servidor al estilo de Phoenix LiveView para Django, con un rendimiento impulsado por Rust. Antes de la versión 1.0.7, `djust.mixins.model_binding.ModelBindingMixin` proporcionaba un controlador de eventos predeterminado llamado `update_model` y formaba parte de la MRO (Method Resolution Order) base de LiveView, por lo que cada vista expone este mecanismo. Utiliza `setattr` para establecer un atributo de la vista cuyo nombre es suministrado por el cliente (`field`), con las siguientes restricciones: se rechazan los nombres que comienzan con `_`; se rechaza una lista negra de 14 entradas correspondientes a componentes internos del framework (`FORBIDDEN_MODEL_FIELDS`); existe `allowed_model_fields`, opcional, que por defecto es None (permitiendo todos); y la existencia mediante `hasattr`. Como resultado, un cliente puede establecer cualquier atributo público existente de la vista, no solo los campos vinculados realmente con `dj-model=` en la plantilla renderizada. La lista negra cubre el mecanismo interno del framework pero nada sobre el estado empresarial o de autorización (authz) del desarrollador, y la lista blanca es opt-in (desactivada por defecto). Un desarrollador que vincule una entrada `dj-model="search"` y también mantenga `self.account_id` / `self.is_admin` / `self.total_price` como estado de vista no se da cuenta de que un cliente puede establecer TODOS ellos mediante `{type:event, event:"update_model", params:{field, value}}` a través del WebSocket. La coerción de tipos coincide con el tipo del atributo objetivo (por lo tanto, `"true"` -> bool True), facilitando al atacante. Este problema se soluciona en djust 1.0.7. Como medida provisional, establezca `allowed_model_fields` explícitamente en cada vista que utilice dj-model (o herede de LiveView) con la lista mínima de campos vinculables; no mantenga el estado de autorización/propiedad en atributos públicos de la vista que compartan espacio con las vinculaciones dj-model.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.