CVE -2026-61599 djust exposes a serious security flaw in djust, a framework for Django that provides real-time interactive rendering. The vulnerability allows unauthenticated remote users to cause the injection of arbitrary Python modules via WebSocket or SSE.
The issue was reported as CVE-2026-61599 djust and affects versions of djust prior to 1.0.7. The security advisory on GitHub classifies the vulnerability as high severity, with a CVSS 4.0 score of 8.8. The fix was released in version 1.0.7.
See also: Browserless: Playwright WebSocket vulnerability exposes files
CVE-2026-61599 djust and WebSocket
djust accepts a path from the client that points to a LiveView class. Before checking whether the class is allowed or whether the user has access rights, the server uses the __import__ to load the module. This means that the top-level code of the module is executed before any security checks are completed.
A remote and unauthenticated user can send special mount, live_redirect_mount or url_change via WebSocket. Similar behavior exists in the SSE route. A constructed value of the form name.module.AnyName for djust to attempt to import an available module.
The impact is not limited to exposing a path. The imported code can cause side effects during startup, load heavy dependencies, and lead to a denial of service. At the same time, different error messages can help enumerate modules and classes present on the server.
The scenario is particularly important for applications that host multiple LiveViews in a shared environment. A module that is not intended for public call can be targeted simply because it is available in the runtime environment. Service isolation and application account privileges limit the potential scope of an attack.
The djust fix in version 1.0.7
According to the CVE-2026-61599 log, version 1.0.7 introduces a new filter before the __import__. The path is checked with the is_view_import_allowed and is only allowed when the module is already loaded in sys.modules or when explicitly included in the LIVEVIEW_ALLOWED_MODULES.
The new logic is applied to the basic WebSocket and SSE paths, and there is additional checking within the view creation process. The change converts the previous behavior from "allow anything that is not blocked" to a restricted list, so that failing a setting does not automatically open access.
The announcement notes that the LIVEVIEW_ALLOWED_MODULES in older versions acts as a partial countermeasure, not a permanent solution. Matching with startswith can allow more paths than the administrator intends, while code still loads before type checking.
For this reason, addressing CVE-2026-61599 djust should not be limited to changing parameters. The upgrade should be tested in a simulated environment to confirm that the allowed LiveView functions continue to load normally without opening new, unexpected paths.
See also: CVE-2026-5430: Vulnerability in WSO2 API Manager
Administrators who cannot upgrade immediately should set LIVEVIEW_ALLOWED_MODULES to as narrow a list as possible. This setting reduces the attack surface, but is not a complete replacement for upgrading, as older versions perform the import before all checks.
What should administrators do?
The basic action is to upgrade djust to 1.0.7 or later. After the change, it is necessary to check that applications only declare the modules required for LiveView functions and that WebSocket services are not accessible from untrusted networks.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
In addition, it is a good idea to examine the logs for unusual mount requests, failed module loading attempts, and repeated errors in view initialization. If the service was exposed to the Internet, administrators should assess a possible breach, rotate credentials, and check the dependencies loaded by the application.
Audits should also cover applications that use SSE, not just WebSocket connections. The common logic of the vulnerability is in the view load path, so a system can remain exposed even when WebSocket ports are not used by the external network.
See also: Google Pixel: Hackers exploit critical vulnerability
CVE -2026-61599 djust shows why user authentication should precede any dynamic code injection. The SecNews technical team recommends installing version 1.0.7 immediately, limiting the allowed modules, and strengthening monitoring of WebSocket and SSE routes.
