What is CVE-2026-61599?

CVE-2026-61599 is a high-severity security vulnerability in djust (pip), affecting versions < 1.0.7. It is fixed in 1.0.7.

Which versions of djust are affected by CVE-2026-61599?

djust (pip) versions < 1.0.7 is affected.

Is there a fix for CVE-2026-61599?

Yes. CVE-2026-61599 is fixed in 1.0.7. Upgrade to this version or later.

Is CVE-2026-61599 exploitable, and should I be worried?

Whether CVE-2026-61599 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk.

What actually determines whether CVE-2026-61599 is exploitable, and how bad it is?

Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.

How do I fix CVE-2026-61599?

Upgrade djust to 1.0.7 or later.

CVE-2026-61599 in djust

Q: Which versions of djust are affected by CVE-2026-61599?

djust (pip) versions < 1.0.7 is affected.

Q: Is there a fix for CVE-2026-61599?

Yes. CVE-2026-61599 is fixed in 1.0.7. Upgrade to this version or later.

Q: Is CVE-2026-61599 exploitable, and should I be worried?

Whether CVE-2026-61599 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk.

Q: What actually determines whether CVE-2026-61599 is exploitable, and how bad it is?

Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.

Q: How do I fix CVE-2026-61599?

Upgrade djust to 1.0.7 or later.

Summary

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

Affected code

python/djust/websocket.py handle_mount (__import__ of the client view)
python/djust/runtime.py ViewRuntime.dispatch_mount / _instantiate_view (SSE + url_change 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.

Workarounds

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

References

Reproducer + finding writeup retained privately by the maintainer.

Impact

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.

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 versions

djust (< 1.0.7)

Security releases

djust → 1.0.7 (pip)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environment New to Kodem? Get a demo →

Remediation advice

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

Frequently Asked Questions

What is CVE-2026-61599? CVE-2026-61599 is a high-severity security vulnerability in djust (pip), affecting versions < 1.0.7. It is fixed in 1.0.7.
Which versions of djust are affected by CVE-2026-61599? djust (pip) versions < 1.0.7 is affected.
Is there a fix for CVE-2026-61599? Yes. CVE-2026-61599 is fixed in 1.0.7. Upgrade to this version or later.
Is CVE-2026-61599 exploitable, and should I be worried? Whether CVE-2026-61599 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
What actually determines whether CVE-2026-61599 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
How do I fix CVE-2026-61599? Upgrade djust to 1.0.7 or later.