djust-org djust up to 1.0.6 Live Transport __import__ view input validation

Summaryinfo

A vulnerability, which was classified as critical, has been found in djust-org djust up to 1.0.6. This issue affects the function __import__ of the component Live Transport. This manipulation of the argument view causes input validation. This vulnerability is tracked as CVE-2026-61599. The attack is possible to be carried out remotely. No exploit exists. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability was found in djust-org djust up to 1.0.6. It has been declared as critical. Affected by this vulnerability is the function __import__ of the component Live Transport. The manipulation of the argument view with an unknown input leads to a input validation vulnerability. The CWE definition for the vulnerability is CWE-20. The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

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.)

It is possible to read the advisory at github.com. This vulnerability is known as CVE-2026-61599 since 07/10/2026. The exploitation appears to be easy. The attack can be launched remotely. The exploitation doesn't need any form of authentication. Technical details of the vulnerability are known, but there is no available exploit.

Upgrading to version 1.0.7 eliminates this vulnerability.

The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2026-81307). Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Vendor

• djust-org

Name

• djust

Version

• 1.0.0
• 1.0.1
• 1.0.2
• 1.0.3
• 1.0.4
• 1.0.5
• 1.0.6

Website

• Product: https://github.com/djust-org/djust/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion