Vulnerabilities

The Python/Django live-view library djust (CVE-2026-61594) fails to enforce standard Django authorization on its WebSocket (live) transport: views are mounted via check_view_auth instead of Django's View.dispatch() chain, so protections such as LoginRequiredMixin, PermissionRequiredMixin, UserPassesTestMixin, login_required decorators, custom dispatch() guards, and the djust admin staff gate apply only to the initial HTTP GET and are silently bypassed over WebSocket. Any anonymous or under-privileged client can open a WebSocket connection and mount such a view, causing its handlers to run. Because all events and state flow over WebSocket, an attacker can reach full read and write handlers — including the djust admin extension's list/create/change/delete operations — yielding high confidentiality and integrity impact (CVSS 3.1: 9.1 critical). All djust deployments that protect WebSocket-mounted views or admin routes with Django mixins, decorators, or overridden dispatch() are affected. No public proof-of-concept is known, the issue is not in CISA KEV, and there are no reports of exploitation in the wild.

Do: Upgrade to djust 1.0.7 or later, where check_view_auth honors the Django AccessMixin family on every transport, system check S004 flags unsafe auth patterns at startup, and the admin mixin enforces login plus active-staff permissions. As an interim workaround, gate WebSocket-mounted views using djust's own login_required, permission_required, or check_permissions attributes instead of HTTP-only Django mixins or decorators. Audit all WebSocket-mounted views (especially admin routes) and review access logs for anonymous WebSocket connections that mounted privileged views.

LMdeploy's AsyncRPCServer (zmq_rpc.py) passes incoming RPC messages directly to pickle.loads() without any sanitization (CWE-502), so anyone who can send a request to the server's TCP endpoint can have it deserialize attacker-controlled pickle data. Because pickle deserialization can instantiate arbitrary objects, an attacker reaching the RPC port gains arbitrary code execution on the host; the researcher demonstrated a full reverse shell from a crafted request. The server performs no validation of the connecting IP, and although its port is randomized, an attacker can find it by port scanning, so any network-reachable deployment is at risk. Affected users are operators running lmdeploy's RPC server component (typically in distributed/multi-node LLM inference setups), especially where the service is reachable beyond localhost or from untrusted networks. No exploitation in the wild is known and the flaw is not in CISA KEV, though the advisory includes working reproduction steps, and the flaw carries a CVSS 3.1 score of 9.8 (critical).

Do: No patched version is identified in the advisory, so monitor the lmdeploy repository/PyPI for a fix and upgrade as soon as one is released; the maintainer-suggested mitigations are replacing pickle with a safer serializer (e.g., msgpack or safetensors) or restricting deserialization via an Unpickler.find_class allowlist, plus enabling RPC authentication. In the meantime, bind the RPC server to localhost or a trusted, firewalled cluster network only, and audit hosts for lmdeploy RPC processes listening on non-local ports.