djust CVE-2026-61599

Reachable against the DEFAULT configuration of djust < 1.0.7: the LIVEVIEW_ALLOWED_MODULES setting is unset by default, and the fail-open if allowed_modules: guard is skipped, so the client-supplied view path is imported with no allowlist enforcement. No authentication is required - the vendor states the WebSocket handshake performs no auth and per-view auth runs only after import + instantiate. Exploitation requires only the ability to reach the djust WebSocket or SSE endpoint and send a mount / live_redirect_mount / url_change (or SSE mount) frame. LIMITING FACTORS: full server code execution is not arbitrary - it is limited to the import-time side effects of modules ALREADY installed/importable on the host (RCE-by-proxy), so guaranteed impact is DoS and an enumeration oracle unless a suitable side-effectful module exists; setting LIVEVIEW_ALLOWED_MODULES to a narrow list mitigates but does not fully fix pre-patch (startswith matching and import still precedes the subclass check).

No CVSS score or vector is provided by NVD or the vendor, so severity signals must be reasoned from the description. The GitHub Security Advisory (GHSA-7prp-2623-8g45) explicitly states an UNAUTHENTICATED WebSocket/SSE client can trigger the flaw, that the WS handshake requires no auth, and that it was reproduced end-to-end - placing this at network attack vector, low complexity, no privileges, no user interaction. CWE-470 (unsafe reflection) fits: a client-supplied dotted path is passed to __import__ before any subclass or auth check. The reliable, unconditional primitives are denial of service (import bombs / expensive dependency trees) and a module/class enumeration oracle via distinct error strings; the headline 'RCE' is more precisely RCE-BY-PROXY - it executes the import-time top-level code of any ALREADY-IMPORTABLE module, so full code execution is CONDITIONAL on a side-effectful module being present on the host, not arbitrary attacker-supplied code. Exploitation status: no CISA KEV entry and no publicly available exploit - the reproducer/writeup is explicitly RETAINED PRIVATELY by the maintainer, so no public POC exists despite a working private one. EPSS is not provided. Net: the vulnerability class is serious and default-configuration-reachable (the allowlist is fail-open when unset, the framework default), making it a genuine priority for any exposed djust deployment; however djust's tiny real-world footprint and the conditionality of full RCE temper absolute risk. Conflict to flag: description asserts 'unauthenticated' and 'RCE', but no CVSS vector exists to independently corroborate the auth level or impact - treat auth as vendor-stated, not vector-confirmed.

An attacker opens an unauthenticated WebSocket (or SSE) connection to a djust-powered Django app running the default configuration (LIVEVIEW_ALLOWED_MODULES unset) and sends a mount frame with view set to any importable Python module path, e.g. an expensive or side-effectful module. The server calls __import__ on that path and executes the module's top-level code before checking it is a LiveView subclass or applying per-view auth, yielding DoS via import bombs, a module-existence oracle, or code execution if a side-effectful importable module exists. A working end-to-end reproducer exists but is held privately by the maintainer, so no public exploit is currently available.