CVE-2026-61599: 
Python 취약성 분석 및 완화

CVE-2026-61599 is an unauthenticated arbitrary module import vulnerability in djust, a Phoenix LiveView-style reactive server-side rendering framework for Django. The flaw exists in versions prior to 1.0.7 and allows any unauthenticated WebSocket or SSE client to cause the server to import — and execute the top-level code of — any importable Python module by supplying a crafted dotted module path in a mount frame. It was published on June 22, 2026, and assigned a CVSS v4 base score of 8.8 (High) (GitHub Advisory).

The root cause is CWE-470 (Use of Externally-Controlled Input to Select Classes or Code / Unsafe Reflection): the djust live transport calls __import__(module_path, ...) using a client-supplied dotted path without first validating it against an allowlist (GitHub Advisory). The LIVEVIEW_ALLOWED_MODULES allowlist is fail-open — when the setting is unset (the framework default), the if allowed_modules: guard is skipped entirely — and even when set, it uses loose startswith matching that can be bypassed. The import and execution of top-level module code occur before the framework checks whether the resolved object is a LiveView subclass and before any per-view authentication runs. Affected sinks are python/djust/websocket.py (handle_mount), python/djust/runtime.py (ViewRuntime.dispatch_mount / _instantiate_view), and python/djust/sse.py (SSE mount). An attacker sends a mount, live_redirect_mount, url_change, or SSE mount frame with view = "<any.importable.module>.AnyName" over an unauthenticated WebSocket connection (GitHub Security Advisory).

Successful exploitation enables server-side execution of arbitrary importable Python modules' import-time side effects by an unauthenticated remote client — effectively RCE-by-proxy on any host that has a side-effectful importable module (e.g., modules that spawn processes, write files, or make network calls at import time). Additionally, an attacker can cause denial of service by triggering import of expensive or recursive dependency trees ("import bombs"), and can use distinct error strings returned by the server as a module and class enumeration oracle to map the server's installed Python environment (GitHub Advisory).

No public proof-of-concept exploit code has been released; the reproducer and finding writeup are retained privately by the maintainer (GitHub Security Advisory). The vulnerability requires no authentication, no privileges, no user interaction, and no special preconditions beyond a reachable djust WebSocket or SSE endpoint, making it trivially exploitable by any network-adjacent attacker. The EPSS score is 0.0 at time of publication, and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing as of the disclosure date (Feedly).

1. Reconnaissance: Identify web applications running djust (pip package djust < 1.0.7) by scanning for Django applications with WebSocket or SSE endpoints, or by inspecting JavaScript bundles for djust-specific frame formats.
2. Establish unauthenticated WebSocket connection: Connect to the target's djust WebSocket endpoint (no authentication is required at the handshake level).
3. Craft a malicious mount frame: Construct a mount, live_redirect_mount, or url_change WebSocket frame (or an SSE mount request) with the view field set to a dotted Python module path targeting a side-effectful module, e.g., view = "os.path.AnyName" or a custom payload module already present on the server's Python path.
4. Trigger arbitrary module import: Send the crafted frame to the server. The djust framework calls __import__(module_path, ...) on the attacker-supplied path before any allowlist check or authentication, executing the module's top-level code.
5. Achieve objective: Depending on the target module's import-time side effects, the attacker can execute arbitrary code (e.g., if a module runs shell commands at import), exfiltrate data, cause denial of service via import bombs, or enumerate installed modules via error message differences (GitHub Security Advisory).

• Network: Unexpected or high-volume WebSocket connections to the djust live transport endpoint from unauthenticated clients; SSE mount requests with unusual or non-application view parameter values containing arbitrary dotted Python module paths.
• Logs: Django/djust application logs showing mount or live_redirect_mount frames with view values referencing modules not part of the application's LiveView definitions; repeated "not a LiveView subclass" rejection errors for unexpected module names; error strings indicating import of standard library or third-party modules (e.g., os, subprocess, importlib).
• Process: Unexpected child processes spawned by the Django/djust server process as a result of import-time side effects (e.g., bash, curl, python, wget); unusual outbound network connections initiated by the server process.
• File System: New or modified files in the application directory or temp directories created by import-time side effects of maliciously triggered modules (GitHub Security Advisory).

Upgrade djust to version 1.0.7, which introduces a fail-closed resolution gate (djust._view_resolution.is_view_import_allowed) that only permits a client-supplied view path if its module is already loaded in sys.modules or explicitly listed in LIVEVIEW_ALLOWED_MODULES with module-segment boundary matching — and the gate runs before any __import__ call at all three vulnerable sinks (GitHub Advisory, v1.0.7 Release). As a temporary workaround for those unable to upgrade immediately, set LIVEVIEW_ALLOWED_MODULES to the narrowest possible list of modules containing your mountable LiveView classes; note that pre-patch this is mitigation only, not a complete fix, because the import still precedes the subclass check (GitHub Security Advisory).

The vulnerability was published to the GitHub Advisory Database on September 16, 2026, and noted on Bluesky via the CVE feed (Bluesky). No significant vendor statements beyond the maintainer's advisory or notable independent researcher commentary have been identified at this time.