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.)