CVE-2026-61596
WysokieCVSS 7.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 23 - wyżej niż 23% wszystkich znanych CVE
Streszczenie
djust przed wersją 1.0.7 nie egzekwuje autoryzacji na poziomie obiektu (get_object + has_object_permission) na trzech ścieżkach renderowania: początkowym renderowaniu HTTP GET, nawigacji SPA url_change oraz osadzonych widokach podrzędnych {% live_render %}. Uwierzytelniony użytkownik może wyświetlać i działać na obiektach, do których nie ma uprawnień, co jest klasycznym IDOR. Problem naprawiono w wersji 1.0.7.
Ocena ryzyka
Uwierzytelniony użytkownik może uzyskać dostęp do nieautoryzowanych obiektów, co może prowadzić do ujawnienia danych lub nieautoryzowanych operacji. Luka dotyczy widoków z niestandardowym get_object.
Rekomendacja
Należy zaktualizować djust do wersji 1.0.7. Do czasu aktualizacji nie należy udostępniać widoków z zakresem obiektowym przez ścieżki HTTP-GET, url_change ani live_render.
Inne podatności w djust
Zobacz wszystkie- CVE-2026-61594Krytyczne
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.
- CVE-2026-113731Niskie
Narzędzie MCP find_handlers_for_template w python/djust/mcp/server.py w wersjach od 0.9.0 do 1.0.10, 1.1.7, 1.2.4 i 1.3.0rc8 przyjmuje istniejącą ścieżkę bezwzględną szablonu i odczytuje ją bez ograniczenia do katalogów projektu. Lokalny klient MCP może wykorzystać narzędzie jako wyrocznię istnienia i czytelności plików oraz uzyskać fragmenty pasujące do wzorca atrybutów z plików czytelnych dla procesu djust.
- CVE-2026-61599Wysokie
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.
- CVE-2026-61589Średnie
W bibliotece djust przed wersją 1.0.7 ścieżka WebSocket (handle_mount i ViewRuntime._build_request) odtwarza HttpRequest bez nagłówka HTTP_HOST, przez co get_host() zwraca "testserver". Powoduje to błędne rozwiązywanie dzierżawcy (tenant) na ścieżce live — przy STRICT_MODE=False może dojść do ujawnienia danych między dzierżawcami, a przy domyślnym ustawieniu do zwracania pustych wyników. Problem naprawiono w wersji 1.0.7.
- CVE-2026-61588Średnie
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.
- CVE-2026-61597Średnie
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.
- CVE-2026-61592Wysokie
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.
- CVE-2026-61591Wysokie
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.
- CVE-2026-61595Wysokie
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.
- CVE-2026-61593Wysokie
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.
Oryginalny opis (angielski, źródło NVD)
djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, djust's per-object authorization (`get_object` + `has_object_permission`, ADR-017) was enforced on the WebSocket mount and event paths but not on three other render entry points: (a) the initial HTTP GET render, (b) SPA `url_change` navigation, and (c) `{% live_render %}` embedded child views. An authenticated user could therefore view (and on some paths act on) an object they are not authorized for by loading the page directly, navigating to it via SPA url-change, or composing it as an embedded child — a classic IDOR / broken object-level access control on object-scoped views. This is fixed in djust 1.0.7. All render entry points now route through a shared `enforce_object_permission` chokepoint: HTTP GET returns 403, `url_change` emits a `permission_denied` frame and skips the render, and `{% live_render %}` (eager + lazy) refuses the embed. Views without a custom `get_object` are unaffected (no-op). No reliable workaround short of upgrading. Do not expose object-scoped views through the HTTP-GET / url_change / live_render paths until patched.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

