CVE-2026-61599: djust has an unauthenticated arbitrary module import via the WebSocket/SSE view-mount path

Impact The djust live transport resolves the LiveView to mount from a client-supplied dotted path by calling import(modulepath, ...). 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 LIVEVIEWALLOWEDMODULES allowlist that should contain this is fail-open (if allowedmodules: — 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 / liveredirectmount / urlchange 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.

Consequences: server-side execution of arbitrary importable modules' import-time side effects by an unauthenticated client (effectively RCE-by-proxy on any host that has a side-effectful importable module), denial of service (import bombs / expensive dependency trees), and a module/class enumeration oracle via distinct error strings.

Reproduced end-to-end: an unauthenticated WebsocketCommunicator mount frame with the allowlist unset imported and executed a sentinel non-LiveView module before the "not a LiveView subclass" rejection.

Affected code - python/djust/websocket.py handlemount (import of the client view) - python/djust/runtime.py ViewRuntime.dispatchmount / instantiateview (SSE + urlchange path) - python/djust/sse.py SSE mount

Threat-model entry T4 (docs/audits/websocket-auth-2026-06.md) previously noted the default-open allowlist but understated the impact as mere LiveView-class probing; the real primitive is arbitrary-module import + top-level code execution, independent of whether the target is a LiveView.

Patches Fixed by a fail-closed resolution gate (djust.viewresolution.isviewimportallowed): 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 LIVEVIEWALLOWEDMODULES 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 instantiateview).

Workarounds Set LIVEVIEWALLOWEDMODULES 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.)

References Reproducer + finding writeup retained privately by the maintainer.