CVE-2026-61599 in djust
Résumé
par VulDB • 17/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, le transport live de djust résout le `LiveView` à monter en se basant sur un chemin pointé fourni par le client via l'appel à `__import__(module_path, ...)`. Le module est importé — exécutant ainsi son code de niveau supérieur (effets secondaires lors des imports) — avant que le framework ne vérifie si l'objet résolu est une sous-classe de `LiveView` et avant toute authentification spécifique à la vue. La liste blanche (`allowlist`) `LIVEVIEW_ALLOWED_MODULES`, qui devrait contenir les modules autorisés, présente un comportement "fail-open" (si `allowed_modules:` — elle est ignorée lorsque le paramètre n'est pas défini, ce qui correspond au défaut du framework) et utilise une correspondance lâche par préfixe (`startswith`). Un client WebSocket non authentifié (la poignée de main WS ne nécessite pas d'authentification ; l'authentification spécifique à la vue s'exécute uniquement après l'importation et l'instanciation) peut donc envoyer un cadre `mount` / `live_redirect_mount` / `url_change` (ou une montée SSE) avec `view = "<nimporte.quel.module.importable>.NimporteQuelNom"` et amener le serveur à importer — et exécuter le code de niveau supérieur de n'importe quel module Python importable par son nom. La version 1.0.7 corrige ce problème grâce à un mécanisme de résolution "fail-closed" (`djust._view_resolution.is_view_import_allowed`) : une vue client est résolue uniquement si (a) son module est déjà chargé (`sys.modules` — la résolution n'exécute donc aucun nouveau code ; les vues routées par URL, chargées au démarrage via `urlconf`, continuent de fonctionner sans configuration supplémentaire) ou (b) elle correspond à `LIVEVIEW_ALLOWED_MODULES` sur une limite de segment de module (opt-in explicite pour les vues importées paresseusement). Ce mécanisme s'exécute avant tout appel à `__import__` aux trois points d'entrée concernés (+ défense en profondeur au sein de `_instantiate_view`). En attendant, définissez `LIVEVIEW_ALLOWED_MODULES` sur la liste étroite des modules contenant vos classes LiveView montables. (Note : avec l'allowlist pré-correction, la correspondance se fait par préfixe (`startswith`) et l'importation précède toujours le contrôle de sous-classe ; il s'agit donc d'une atténuation et non d'une correction complète.)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.