CVE-2026-61589

Podatność w bibliotece djust (przed wersją 1.0.7) pozwala nieuwierzytelnionemu klientowi WebSocket na wywołanie importu dowolnego modułu Pythona poprzez spreparowaną ścieżkę widoku. Import wykonywany jest przed weryfikacją klasy LiveView i autoryzacją, a lista dozwolonych modułów jest domyślnie otwarta (fail-open) i używa luźnego dopasowania.

W bibliotece djust przed wersją 1.0.7 przypisanie instancji modelu Django do publicznego atrybutu widoku powodowało serializację całego obiektu do klienta bez listy zabronionych pól wrażliwych. W efekcie do przeglądarki trafiały takie dane jak hash hasła, flagi uprawnień (is_staff, is_superuser), tokeny i inne dane osobowe. Problem naprawiono w wersji 1.0.7.

Przed wersją 1.0.7, wiele wbudowanych tagów szablonów komponentów djust renderuje URL dostarczony przez programistę/użytkownika w atrybucie href/action, uciekając go HTML-em, ale nie walidując schematu URL. Ucieczka HTML zapobiega wydostaniu się z atrybutu, ale nie neutralizuje URI javascript:, więc URL taki jak javascript:alert(document.cookie) trafia dosłownie do <a href="javascript:alert(document.cookie)"> i wykonuje się w sesji ofiary po kliknięciu.

W bibliotece djust przed wersją 1.0.7 sesje SSE były identyfikowane wyłącznie przez wybrany przez klienta parametr session_id, bez powiązania z uwierzytelnionym użytkownikiem. Atakujący, który pozna session_id ofiary, mógł połączyć się z endpointem wiadomości i wywoływać handlery zdarzeń działające w kontekście tożsamości i stanu ofiary.

W bibliotece djust przed wersją 1.0.7 dla widoków korzystających z migawek stanu, pole state_json osadzone w stronie klienta było przywracane po ponownym połączeniu jako zaufany stan widoku bez weryfikacji integralności. Klient mógł edytować niepodpisany state_json i wstrzyknąć dowolne atrybuty widoku, np. ustawić is_admin na True lub zmienić account_id/balance.

djust zapewnia reaktywne renderowanie po stronie serwera w stylu Phoenix LiveView dla Django z wydajnością opartą na Rust. W wersjach przed 1.0.7 izolacja djust.tenants była wymuszana tylko na ścieżce HTTP; bieżący najemca był przechowywany w threading.local() i ustawiany wyłącznie przez TenantMiddleware, więc na ścieżce live (WebSocket/SSE) get_current_tenant() zawsze zwracał None, a menedżer QuerySet zawodził w trybie OPEN, ujawniając wiersze wszystkich najemców. Problem naprawiono w wersji 1.0.7.

djust zapewnia reaktywne renderowanie po stronie serwera w stylu Phoenix LiveView dla Django z wydajnością opartą na Rust. W wersjach przed 1.0.7 endpointy POST SSE klient→serwer są oznaczone @csrf_exempt, a endpoint GET strumienia SSE nie sprawdzał nagłówka Origin, więc strona cross-origin mogła przejąć sesję SSE uwierzytelnioną ciasteczkiem ofiary i wywoływać zmieniające stan procedury obsługi zdarzeń. Problem naprawiono w wersji 1.0.7.

Podatność w bibliotece djust (wersje przed 1.0.7) dotyczy domyślnego handlera zdarzenia `update_model` w `ModelBindingMixin`, który pozwala klientowi ustawić dowolny publiczny atrybut widoku poprzez WebSocket, a nie tylko pola powiązane z `dj-model=`. Ochrona opiera się jedynie na odrzucaniu nazw z prefiksem `_`, 14-elementowej denylistcie wewnętrznych pól frameworka oraz opcjonalnej allowliście, która domyślnie zezwala na wszystko. W efekcie atakujący może modyfikować atrybuty takie jak `account_id`, `is_admin` czy `total_price`, jeśli są publiczne i istnieją w widoku.

W bibliotece djust przed wersją 1.0.7 punkty końcowe observability ujawniają stan live view/session oraz powierzchnię zdalnego wywoływania metod (eval_handler). Ograniczenie do localhost było opcjonalnym middleware, którego udokumentowana konfiguracja nie zawiera, a widoki wymuszały jedynie DEBUG. W scenariuszu zgodnym z dokumentacją (DEBUG włączone, brak middleware) klient spoza localhost mógł odczytać stan aplikacji i zdalnie wywoływać handlery.

djust przed wersją 1.0.7 ma podatność w transporcie WebSocket, która omija standardowe mechanizmy autoryzacji Django (takie jak LoginRequiredMixin, PermissionRequiredMixin itp.) oraz bramkę dla personelu w rozszerzeniu administracyjnym. Autoryzacja mounta odbywa się przez check_view_auth, a nie przez łańcuch View.dispatch(), co pozwala anonimowym lub nieuprzywilejowanym klientom na otwarcie WebSocket i wywołanie handlerów widoków, w tym administracyjnych.