CVE-2026-61594 in djust
Zusammenfassung
von VulDB • 17.09.2026
djust bietet Phoenix LiveView-ähnliches reaktives serverseitiges Rendering für Django mit Rust-gestützter Performance. Vor Version 1.0.7 autorisiert der live (WebSocket)-Transport eine Mount-Operation über `check_view_auth` und nicht über die Django’sche `View.dispatch()`-Kette. Infolgedessen wurden standardmäßige Django-Autorisierungsmechanismen – `LoginRequiredMixin`, `PermissionRequiredMixin`, `UserPassesTestMixin`, `@method_decorator(login_required, name="dispatch")` sowie benutzerdefinierte `dispatch()`-Prüfungen – und das Staff-Gate der djust Admin-Erweiterung (das nur im HTTP-Wrapper `as_view` angewendet wird) bei der initialen HTTP GET-Anfrage durchgesetzt, über WebSocket jedoch stillschweigend umgangen, wo alle Ereignisse und Zustandsflüsse ablaufen. Ein anonymer oder nicht ausreichend privilegierter Client konnte ein WebSocket öffnen und eine solche View mounten – einschließlich Admin-Listen-/Erstellungs-/Änderungs-/Löschoperationen – sowie deren Handler aufrufen. Dies wurde in djust 1.0.7 behoben. `check_view_auth` respektiert nun die Django `AccessMixin`-Familie bei jedem Transport; eine neue Systemprüfung S004 schlägt beim Start mit einer deutlichen Fehlermeldung fehl, wenn Authentifizierungsmuster vorliegen, die zur Laufzeit nicht sicher wiedergegeben werden können (Decorator-/überschriebene-`dispatch`-Formen); und das Admin-Basis-Mixin deklariert `login_required = True` sowie ein aktives Staff-Gate über `check_permissions`. Als Workaround sollten Views mit den djust-Attributen `login_required`, `permission_required` oder `check_permissions` gesichert werden (die auf allen Transports respektiert werden), anstatt HTTP-only-Mixins/Decorators zu verwenden.
Once again VulDB remains the best source for vulnerability data.