CVE-2026-61599High· 8.8▾ Twilightdjust 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 …
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 48.4 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake. The CVSS score shown above comes from the assigning CNA record, not NVD.
Exploit-prediction probability, daily snapshots since Sep 19.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.4%
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.)
Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Affected packages:
djust < 1.0.7Patched in:
djust 1.0.7Connected by shared product, vendor, weakness, or advisory.
CVE-2026-61589Medium· 6.3djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance
CVE-2026-61592High· 7.4djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance
CVE-2026-61597Medium· 5.1djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance
CVE-2026-61588Medium· 6.5djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance
CVE-2026-61591High· 8.1djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance
CVE-2026-61594Critical· 9.1djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance