CVE-2026-61599
HIGHDescription
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.)
How to fix
No published remediation has been found for this vulnerability's affected products yet.
Mitigation guidance may be in the linked vendor advisories in the References section below.
TridentStack Control tracks known vulnerabilities across your Windows, macOS, and Linux fleet and shows the fix as soon as one is published. See how it works
CVSS v4 Vector
Exploitability
Impact
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Exploit Intelligence
EPSS data unavailable for this CVE.
References
Related Vulnerabilities
Other CWE-470 vulnerabilities, ordered by exploit likelihood. View all
| CVE | Severity | CVSS | EPSS | Exploited | Fix |
|---|---|---|---|---|---|
| CVE-2021-21985 | Critical | 9.8 | 100% | KEV + Ransom | Fix |
| CVE-2024-4990 | Critical | 9.1 | 80% | - | - |
| CVE-2024-0200 | High | 7.2 | 72% | - | Fix |
| CVE-2022-30287 | High | 8.0 | 71% | - | Fix |
| CVE-2025-3600 | High | 7.5 | 24% | - | - |
| CVE-2018-5511 | High | 7.2 | 14% | - | - |
Common questions
How do I fix CVE-2026-61599?
No published fix for CVE-2026-61599 has been found yet. Check the linked vendor advisories for guidance as it becomes available.
How severe is CVE-2026-61599?
CVE-2026-61599 has a CVSS v4 base score of 8.8, rated high. CVSS rates the technical impact if the vulnerability is exploited, not how likely that is, so weigh it alongside the exploit-prediction score when you decide what to patch first.
Embed a live status badge for CVE-2026-61599
Markdown
[](https://tridentstack.com/cve/CVE-2026-61599)HTML
<a href="https://tridentstack.com/cve/CVE-2026-61599"><img src="https://tridentstack.com/cve/badge/CVE-2026-61599.svg" alt="CVE-2026-61599"></a>Find and fix vulnerabilities across your fleet
TridentStack Control continuously scans your Windows, macOS, and Linux fleet for known vulnerabilities, prioritizes them by severity and active exploitation, and patches them automatically.
This product uses NVD data but is not endorsed or certified by the NVD. EPSS scores courtesy of FIRST.org (https://www.first.org/epss). Source: CISA KEV Catalog. Data as of 2026-09-17.