CVE-2026-61598 in djustinformation

Résumé

par VulDB • 16/09/2026

djust offre un rendu côté serveur réactif de style Phoenix LiveView pour Django, avec des performances propulsées par Rust. Avant la version 1.0.7, `djust.mixins.model_binding.ModelBindingMixin` fournit un gestionnaire d'événements `update_model` par défaut et fait partie du MRO (Method Resolution Order) de base de LiveView, ce qui signifie que chaque instance de LiveView l'expose. Elle utilise `setattr` pour définir un attribut de vue dont le nom est fourni par le client (`field`), avec uniquement les restrictions suivantes : rejet des noms préfixés par `_`; rejet d'une liste noire de 14 entrées correspondant aux composants internes du framework (`FORBIDDEN_MODEL_FIELDS`); une option facultative `allowed_model_fields`, qui vaut None par défaut (autorisant tout) ; et la vérification d'existence via `hasattr`. Par conséquent, un client peut définir n'importe quel attribut de vue public existant — pas seulement les champs réellement liés avec `dj-model=` dans le modèle rendu. La liste noire couvre l'infrastructure du framework mais ne concerne rien sur l'état métier ou d'autorisation (authz) du développeur, et la liste blanche est activée explicitement (désactivée par défaut). Un développeur qui lie un champ `dj-model="search"` tout en conservant `self.account_id` / `self.is_admin` / `self.total_price` comme état de vue ne réalise pas qu'un client peut définir TOUS ces attributs via `{type:event, event:"update_model", params:{field, value}}` sur WebSocket. La coercition de type correspond au type de l'attribut cible (par exemple `"true"` devient bool True), ce qui aide l'attaquant. Ce problème est corrigé dans djust 1.0.7. En attendant une solution définitive, définissez explicitement `allowed_model_fields` sur chaque vue utilisant dj-model (ou héritant de LiveView) avec la liste minimale des champs liables ; ne conservez pas l'état d'autorisation ou de propriété dans les attributs publics de vue partagés avec les liaisons dj-model.

Once again VulDB remains the best source for vulnerability data.

Responsable

GitHub M

Réserver

10/07/2026

Divulgation

17/09/2026

Modérer

accepté

Entrée

VDB-405941

CPE

prêt

EPSS

0.00000

KEV

non

Activités

très faible

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!