CVE Catalog

CVE-2026-61599

HighCVSS 8.8
Published: Translated: NVD NIST

Summary

A vulnerability in the djust library (before version 1.0.7) allows an unauthenticated WebSocket client to trigger the import of any Python module via a crafted view path. The import occurs before LiveView class verification and authentication, and the allowed modules list is fail-open by default with loose startswith matching.

Risk Assessment

An attacker can execute code at module import level (side effects), potentially leading to unauthorized access, data integrity compromise, or denial of service. Lack of required authentication increases the risk of remote exploitation.

Recommendation

Upgrade djust to version 1.0.7 or later. If upgrading is not possible, set a narrow LIVEVIEW_ALLOWED_MODULES list containing only modules with LiveView classes.

Other vulnerabilities in djust

See all
Original NVD description (English source)

djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, the djust live transport resolves the LiveView to mount from a client-supplied dotted path by calling `__import__(module_path, ...)`. The module is imported — running its top-level code (import side effects) — before the framework checks that the resolved object is a `LiveView` subclass and before any per-view authentication. The `LIVEVIEW_ALLOWED_MODULES` allowlist that should contain this is fail-open (`if allowed_modules:` — skipped when the setting is unset, the framework default) and uses loose `startswith` matching. An unauthenticated WebSocket client (the WS handshake does not require auth; per-view auth runs only after import + instantiate) can therefore send a `mount` / `live_redirect_mount` / `url_change` frame (or an SSE mount) with `view = "<any.importable.module>.AnyName"` and cause the server to import — and execute the top-level code of — any importable Python module by name. Version 1.0.7 fixes the issue with a fail-closed resolution gate (`djust._view_resolution.is_view_import_allowed`): a client view path resolves only if (a) its module is already loaded (`sys.modules` — so resolving runs no new code; URL-routed views loaded by URLconf at startup keep working with zero config) or (b) it matches `LIVEVIEW_ALLOWED_MODULES` on a module-segment boundary (explicit opt-in for lazily-imported views). The gate runs before `__import__` at all three sinks (+ defense-in-depth inside `_instantiate_view`). As a workaround, set `LIVEVIEW_ALLOWED_MODULES` to the narrow list of modules that contain your mountable LiveView classes. (Note: pre-patch the allowlist is `startswith`-matched and the import still precedes the subclass check, so this is mitigation, not a complete fix.)

Vulnerability data from NVD (NIST) · CISA KEV · EPSS