CVE-2026-61599
- Source
- https://cve.org/CVERecord?id=CVE-2026-61599
- Import Source
- https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-61599.json
- JSON Data
- https://api.osv.dev/v1/vulns/CVE-2026-61599
- Aliases
- Published
- 2026-09-16T22:11:45Z
- Modified
- 2026-09-18T03:48:29Z
- Severity
-
- 8.8 (High) CVSS_V4 - 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 CVSS Calculator
- Summary
- djust has an unauthenticated arbitrary module import via the WebSocket/SSE view-mount path
- Details
-
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 aLiveViewsubclass and before any per-view authentication. TheLIVEVIEW_ALLOWED_MODULESallowlist that should contain this is fail-open (if allowed_modules:— skipped when the setting is unset, the framework default) and uses loosestartswithmatching. An unauthenticated WebSocket client (the WS handshake does not require auth; per-view auth runs only after import + instantiate) can therefore send amount/live_redirect_mount/url_changeframe (or an SSE mount) withview = "<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 matchesLIVEVIEW_ALLOWED_MODULESon 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, setLIVEVIEW_ALLOWED_MODULESto the narrow list of modules that contain your mountable LiveView classes. (Note: pre-patch the allowlist isstartswith-matched and the import still precedes the subclass check, so this is mitigation, not a complete fix.) - Database specific
{ "cna_assigner": "GitHub_M", "cwe_ids": [ "CWE-470" ], "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/61xxx/CVE-2026-61599.json" }- References