CVE-2026-61589
ŚrednieCVSS 6.3Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 7 - wyżej niż 7% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
W przypadku aplikacji wielodzierżawczych z STRICT_MODE=False atakujący może uzyskać dostęp do danych innych dzierżawców (cross-tenant disclosure). Przy domyślnej konfiguracji może wystąpić awaria izolacji dzierżawców, prowadząca do błędnego działania aplikacji.
Rekomendacja
Zaktualizuj djust do wersji 1.0.7 lub nowszej. Do czasu aktualizacji unikaj używania STRICT_MODE=False na ścieżce live; nie ma znanego obejścia dla tego problemu.
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-61596Wysokie
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.
- 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, the WebSocket `handle_mount` and `ViewRuntime._build_request` rebuild an `HttpRequest` via `RequestFactory().get(...)` with no `HTTP_HOST`, so `request.get_host()` defaulted to `"testserver"` on the live path. Host/subdomain/domain `TenantResolver`s then misresolved the tenant — `None` on the live path while the HTTP path resolved correctly. With `STRICT_MODE=False` the tenant-scoped managers returned unscoped rows (cross-tenant disclosure); with the default they returned an empty queryset (broken tenancy). This is fixed in djust 1.0.7. The handshake Host is extracted from the ASGI scope, validated against `ALLOWED_HOSTS` (the same logic as the CSWSH Origin gate, parsed with Django's `split_domain_port` so malformed Hosts are rejected at the boundary), and propagated — with the TLS scheme — into the reconstructed request, so live-path tenant resolution matches HTTP exactly. There is no known workaround on the live path short of upgrading. Users are most exposed when combined with `STRICT_MODE=False`.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

