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 = "<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.)
Published: 2026-09-16
Score: 8.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Remote Code Execution
Action: Immediate Patch
AI Analysis

Impact

A client can supply a dotted path for the LiveView module via a WebSocket or SSE mount frame, and the framework imports that module before checking that it is a LiveView subclass or validating the user. The import executes the module’s top‑level code, giving the attacker the ability to run arbitrary Python code on the server. This vulnerability is a classic arbitrary code execution flaw identified as CWE‑470.

Affected Systems

The djust framework from djust-org is affected in all releases older than version 1.0.7. The security advisory indicates that the issue was resolved in release 1.0.7.

Risk and Exploitability

The CVSS score of 8.8 highlights a high severity vulnerability, but the EPSS score is below 1%, suggesting it is currently rarely exploited. The vulnerability is not listed in the CISA KEV catalog. Attackers need only reach the unprotected WebSocket endpoint to send a specially crafted mount frame; authentication checks run only after the import, so no credentials are required. Once the frame is processed, the server executes the attacker‑supplied module, potentially giving full code‑execution privileges.

Generated by OpenCVE AI on September 17, 2026 at 22:21 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade djust to version 1.0.7 or later to apply the fix that closes the import gate.
  • Configure the LIVEVIEW_ALLOWED_MODULES setting to a narrow list that includes only trusted modules that contain LiveView classes.
  • Restrict or authenticate the WebSocket/SSE endpoint so that only trusted clients can send mount frames, reducing the surface for this exploit.

Generated by OpenCVE AI on September 17, 2026 at 22:21 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Github GHSA Github GHSA GHSA-7prp-2623-8g45 djust has an unauthenticated arbitrary module import via the WebSocket/SSE view-mount path
History

Thu, 17 Sep 2026 22:30:00 +0000

Type Values Removed Values Added
First Time appeared Djust-org
Djust-org djust
Vendors & Products Djust-org
Djust-org djust

Thu, 17 Sep 2026 14:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Wed, 16 Sep 2026 22:30:00 +0000

Type Values Removed Values Added
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 = "<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.)
Title djust has an unauthenticated arbitrary module import via the WebSocket/SSE view-mount path
Weaknesses CWE-470
References
Metrics cvssV4_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'}

Subscriptions

Djust-org Djust
cve-icon MITRE

Status: PUBLISHED

Assigner: GitHub_M

Published:

Updated: 2026-09-17T13:21:22.309Z

Reserved: 2026-07-10T17:12:17.238Z

Link: CVE-2026-61599

cve-icon Vulnrichment

Updated: 2026-09-17T13:21:18.180Z

cve-icon NVD

Status : Deferred

Published: 2026-09-16T23:16:54.010

Modified: 2026-09-30T17:51:56.193

Link: CVE-2026-61599

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-17T22:30:17Z

Weaknesses
  • CWE-470

    Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')