{"id":"CVE-2026-61599","aliases":["EUVD-2026-81307","GHSA-7prp-2623-8g45","PYSEC-2026-4038"],"status":"published","title":"djust has an unauthenticated arbitrary module import via the WebSocket/SSE view-mount path","description":"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 = \"\u003cany.importable.module\u003e.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.)","severity":{"version":"4.0","score":8.8,"vector":"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","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00604,"percentile":0.49183,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-470"],"published":"2026-09-16T22:09:38Z","modified":"2026-11-05T23:15:04Z","fixes":[{"ecosystem":"PyPI","package":"djust","fixed_in":["1.0.7"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"djust","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.0.7"}]}]},{"source":"osv","ecosystem":"PyPI","package":"djust","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.0.7"}]}],"versions":["0.1.0","0.1.2","0.1.3","0.1.4","0.1.5","0.1.6","0.1.7","0.1.8","0.1.9","0.2.0","0.2.1","0.2.2","0.3.0","0.3.1","0.3.2","0.3.4","0.3.5","0.3.6","0.3.7","0.3.8","0.4.0","0.4.1","0.4.2","0.4.3","0.4.4","0.9.0","0.9.1","0.9.2","0.9.4","0.9.5","0.9.6","0.9.7","1.0.0","1.0.0rc11","1.0.1","1.0.2","1.0.3","1.0.4","1.0.5","1.0.6"]},{"source":"osv","ecosystem":"PyPI","package":"djust","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.0.7"}]}],"versions":["0.1.0","0.1.2","0.1.3","0.1.4","0.1.5","0.1.6","0.1.7","0.1.8","0.1.9","0.2.0","0.2.1","0.2.2","0.3.0","0.3.1","0.3.2","0.3.4","0.3.5","0.3.6","0.3.7","0.3.8","0.4.0","0.4.1","0.4.2","0.4.3","0.4.4","0.9.0","0.9.1","0.9.2","0.9.4","0.9.5","0.9.6","0.9.7","1.0.0","1.0.0rc11","1.0.1","1.0.2","1.0.3","1.0.4","1.0.5","1.0.6"]}],"products":[{"vendor":"djust-org","product":"djust"}],"references":[{"url":"https://github.com/djust-org/djust/security/advisories/GHSA-7prp-2623-8g45","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/djust-org/djust/releases/tag/v1.0.7","tags":["x_refsource_MISC","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-61599","tags":["advisory"]},{"url":"https://github.com/djust-org/djust/commit/04985e2f6a69faf265fc512b323d28adaa15c3ff","tags":["web"]},{"url":"https://github.com/advisories/GHSA-7prp-2623-8g45","tags":["advisory"]},{"url":"https://github.com/djust-org/djust","tags":["package"]},{"url":"https://github.com/pypa/advisory-database/tree/main/vulns/djust/PYSEC-2026-4038.yaml","tags":["web"]},{"url":"https://pypi.org/project/djust","tags":["web","package"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/61xxx/CVE-2026-61599.json","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-61599","title":"djust has an unauthenticated arbitrary module import via the WebSocket/SSE view-mount path","description":"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 = \"\u003cany.importable.module\u003e.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.)","status":"published","published":"2026-09-16T22:11:45.78Z","modified":"2026-09-17T13:21:22.309Z","cvss":[{"version":"4.0","score":8.8,"vector":"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","level":"high","assessor":"cna"}],"cwes":["CWE-470"],"updated_at":"2026-11-02T14:19:53.4444Z"}],"euvd":[{"id":"EUVD-2026-81307","description":"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 = \"\u003cany.importable.module\u003e.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.)","status":"published","published":"2026-09-16T22:11:45Z","modified":"2026-09-17T13:21:22Z","cvss":[{"version":"4.0","score":8.8,"vector":"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","level":"high"}],"updated_at":"2026-11-02T17:28:12.719968Z"}],"ghsa":[{"id":"GHSA-7prp-2623-8g45","title":"djust has an unauthenticated arbitrary module import via the WebSocket/SSE view-mount path","description":"### Impact\nThe 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.\n\nAn **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 = \"\u003cany.importable.module\u003e.AnyName\"` and cause the server to import — and execute the top-level code of — **any importable Python module by name**.\n\n**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.\n\nReproduced 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.\n\n### Affected code\n- `python/djust/websocket.py` `handle_mount` (`__import__` of the client `view`)\n- `python/djust/runtime.py` `ViewRuntime.dispatch_mount` / `_instantiate_view` (SSE + `url_change` path)\n- `python/djust/sse.py` SSE mount\n\nThreat-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.\n\n### Patches\nFixed by 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`).\n\n### Workarounds\nSet `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.)\n\n### References\nReproducer + finding writeup retained privately by the maintainer.","status":"published","published":"2026-09-16T22:09:38Z","modified":"2026-11-05T23:01:11Z","cvss":[{"version":"4.0","score":8.8,"vector":"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","level":"high"}],"cwes":["CWE-470"],"updated_at":"2026-11-05T23:26:59.445059Z"}],"nvd":[{"id":"CVE-2026-61599","description":"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 = \"\u003cany.importable.module\u003e.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.)","status":"published","published":"2026-09-16T23:16:54.01Z","modified":"2026-09-30T17:51:56.193Z","cvss":[{"version":"4.0","score":8.8,"vector":"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","level":"high","assessor":"secondary"}],"cwes":["CWE-470"],"updated_at":"2026-11-02T14:12:49.013904Z"}],"osv":[{"id":"CVE-2026-61599","title":"djust has an unauthenticated arbitrary module import via the WebSocket/SSE view-mount path","description":"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 = \"\u003cany.importable.module\u003e.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.)","status":"published","published":"2026-09-16T22:11:45.78Z","modified":"2026-10-28T02:30:30.147544685Z","cvss":[{"version":"4.0","score":8.8,"vector":"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","level":"high"}],"cwes":["CWE-470"],"updated_at":"2026-11-02T15:45:12.933503Z"},{"id":"GHSA-7prp-2623-8g45","title":"djust has an unauthenticated arbitrary module import via the WebSocket/SSE view-mount path","description":"### Impact\nThe 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.\n\nAn **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 = \"\u003cany.importable.module\u003e.AnyName\"` and cause the server to import — and execute the top-level code of — **any importable Python module by name**.\n\n**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.\n\nReproduced 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.\n\n### Affected code\n- `python/djust/websocket.py` `handle_mount` (`__import__` of the client `view`)\n- `python/djust/runtime.py` `ViewRuntime.dispatch_mount` / `_instantiate_view` (SSE + `url_change` path)\n- `python/djust/sse.py` SSE mount\n\nThreat-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.\n\n### Patches\nFixed by 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`).\n\n### Workarounds\nSet `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.)\n\n### References\nReproducer + finding writeup retained privately by the maintainer.","status":"published","published":"2026-09-16T22:09:38Z","modified":"2026-11-05T23:15:04.327493047Z","cvss":[{"version":"4.0","score":8.8,"vector":"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","level":"high"}],"cwes":["CWE-470"],"updated_at":"2026-11-05T23:31:51.608951Z"},{"id":"PYSEC-2026-4038","title":"djust has an unauthenticated arbitrary module import via the WebSocket/SSE view-mount path","description":"### Impact\nThe 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.\n\nAn **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 = \"\u003cany.importable.module\u003e.AnyName\"` and cause the server to import — and execute the top-level code of — **any importable Python module by name**.\n\n**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.\n\nReproduced 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.\n\n### Affected code\n- `python/djust/websocket.py` `handle_mount` (`__import__` of the client `view`)\n- `python/djust/runtime.py` `ViewRuntime.dispatch_mount` / `_instantiate_view` (SSE + `url_change` path)\n- `python/djust/sse.py` SSE mount\n\nThreat-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.\n\n### Patches\nFixed by 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`).\n\n### Workarounds\nSet `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.)\n\n### References\nReproducer + finding writeup retained privately by the maintainer.","status":"published","published":"2026-10-01T16:38:32.198167Z","modified":"2026-10-01T17:45:02.043021561Z","cvss":[{"version":"4.0","score":8.8,"vector":"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","level":"high"}],"updated_at":"2026-11-02T15:52:57.255153Z"}]}}