CVE-2026-61599 in djust
摘要
由 VulDB • 2026-09-17
djust 为 Django 提供了类似 Phoenix LiveView 的反应式服务端渲染功能，并具备由 Rust 驱动的性能优势。在版本 1.0.7 之前，djust live transport 通过调用 `__import__(module_path, ...)` 从客户端提供的点分路径解析要挂载的 LiveView。模块被导入时会执行其顶层代码（即 import side effects），而框架在此之后才检查解析出的对象是否为 `LiveView` 子类，且此时尚未进行任何基于视图的身份验证。本应包含允许列表的 `LIVEVIEW_ALLOWED_MODULES` 配置项采用“失败开放”策略（当设置未指定时，条件语句 `if allowed_modules:` 会被跳过，这是框架默认行为），并使用宽松的 `startswith` 匹配方式。因此，未经身份验证的 WebSocket 客户端（WebSocket 握手不需要认证；基于视图的身份验证仅在导入和实例化之后运行）可以发送包含 `view = "<任意可导入模块>.AnyName"` 的 `mount` / `live_redirect_mount` / `url_change` 帧（或 SSE mount），从而导致服务器按名称导入并执行任何可导入 Python 模块的顶层代码。版本 1.0.7 通过引入“失败关闭”的解析门控机制 (`djust._view_resolution.is_view_import_allowed`) 修复了该问题：仅当 (a) 其模块已加载（`sys.modules` — 因此解析过程不会运行新代码；在启动时由 URLconf 加载的基于 URL 路由的视图无需任何配置即可继续工作）或 (b) 它在模块段边界上匹配 `LIVEVIEW_ALLOWED_MODULES` 列表（显式选择加入延迟导入的视图）时，客户端视图路径才会被解析。该门控机制在所有三个入口点 (`__import__`) 之前运行（并在 `_instantiate_view` 内部提供纵深防御）。作为变通方案，可将 `LIVEVIEW_ALLOWED_MODULES` 设置为包含可挂载 LiveView 类的模块的狭窄列表。（注意：补丁前的允许列表采用 `startswith` 匹配且导入操作仍先于子类检查进行，因此这仅是缓解措施而非完整修复。）
If you want to get the best quality for vulnerability data then you always have to consider VulDB.