Clash Party 内置 Sub-Store 风险怎么处理？

Sub-Store issue #634 的公开报告把受影响范围写为 Node 后端 2.11.4 至 2.37.1，并描述了过宽的跨来源访问与脚本处理能力组合后的风险。上游随后用提交 038745f 收紧默认 CORS、限制部分 Node 脚本操作并增加拒绝测试，2.38.0 的发布说明明确关闭该 issue。

截至 2026 年 9 月 12 日，Sub-Store 当前稳定版是 2.39.6。本文把 2.38.0 作为上游明确关闭 #634 的最低版本边界，并建议更新到当前稳定版；这不等于 2.38.0 为所有网络暴露增加了认证，也不能据版本号判断设备是否已经受到影响。

Clash Party issue #2134 是一条针对 v2.0.2 环境的用户报告，随后按项目安全报告流程由机器人关闭，贡献者建议更新 Sub-Store。Clash Party 可以独立更新内置后端，所以只看客户端版本无法确定正在运行的 Sub-Store 版本。

v2.0.2 源码把内置 Sub-Store 设为默认启用，但实际状态仍以本机设置和监听结果为准。没有打开过页面、隐藏入口或删除一条订阅，都不等于后端已经停用。

如果 Clash Party 正在运行 Sub-Store，但你还不知道后端版本，先关闭不受信任的网页，不要寻找或运行公开利用代码。打开 Clash Party 的“设置 > Sub-Store”，关闭“启用 Sub-Store”；官方源码显示，这个动作会停止内置前端和后端服务。

同时确认“允许局域网访问”保持关闭。该选项打开时服务会绑定 0.0.0.0，局域网设备可直接访问；关闭时使用 127.0.0.1。公开报告包含浏览器页面访问回环地址的路径，所以只关局域网访问不能代替更新，但它能避免继续扩大网络暴露面。

Sub-Store 是订阅编辑、转换和管理工具，不是 Mihomo 核心本身。停用后，已经导入 Clash Party 的 Profile、策略组、系统代理和 TUN 通常仍可继续工作，只是不能继续使用 Sub-Store 页面处理订阅。

准备更新时，先在“设置 > Sub-Store”确认使用的是内置后端还是自定义后端。内置模式由 Clash Party 启动本地 bundle；自定义模式会停止内置后端并连接用户填写的 URL，应用内更新不能替代外部部署自己的升级、监听限制和鉴权。

使用内置后端时，确保不受信任的网页已经关闭，再临时启用 Sub-Store，并保持该设置区的“允许局域网访问”关闭。进入 Sub-Store 页面使用“在浏览器中打开”，以界面给出的实际地址为准，不要假设每台设备都固定使用同一个端口。

Clash Party v2.0.2 源码显示，后端默认从 127.0.0.1:38324 开始寻找可用端口，若端口已占用会继续递增。打开后端根地址时，Sub-Store 的响应会在 data.version 中给出实际版本；只记录版本和地址，不提交脚本参数或进行利用测试。

若版本落在 2.11.4 至 2.37.1，应立即更新；若版本低于 2.11.4，虽不在该报告范围，也已经明显落后，应更新到当前稳定版；若页面打不开或版本无法确认，则回到停用状态，不要把“未知”当成安全。

下面的步骤只适用于 Clash Party 内置后端。Sub-Store 页面右上角有云形“检查更新”按钮；v2.0.2 源码显示，该入口会从 sub-store-org/Sub-Store 官方 Release 的 latest 下载后端与前端文件，完成后重启两项服务。

点击更新后等待完成提示，不在中途退出客户端，也不要同时手工覆盖应用目录中的 bundle。最低目标是 2.38.0，当前目标是 2026 年 9 月 11 日发布的 2.39.6；若未来已有更新稳定版，应以官方 Releases 为准。

更新 Mihomo 内核、刷新订阅或重新安装相同的 Clash Party 客户端，都不能替代核对 Sub-Store 后端。它是独立下载和运行的组件，必须在自己的页面完成更新并读取自己的版本号。

更新提示成功只是第一层验证。重启 Clash Party 后，再从 Sub-Store 页面读取实际后端地址和 data.version，确认版本没有回到旧值；同时确认地址使用 127.0.0.1，而不是局域网地址或 0.0.0.0。

然后关闭“启用 Sub-Store”，确认前端和后端页面不再可用，再用现有 Profile 完成一次真实 HTTPS 请求。这样可以同时证明停用开关确实停止独立服务，也证明普通代理并不依赖 Sub-Store 持续运行。

版本落在报告范围不等于已经被利用。只有出现未知进程、异常网络连接、系统安全软件告警、配置或凭据被异常改动等证据时，才应把事件升级为可能的设备入侵；此时更新只能封堵后续入口，不能删除已经存在的程序或恢复泄露的凭据。

先停用 Sub-Store 并断开设备网络，记录 Clash Party 与 Sub-Store 版本、监听地址、告警时间和可疑现象。不要为了“清理”而立即删除日志、配置或未知文件，它们可能是判断影响范围的重要证据。

使用操作系统或企业已批准的安全工具做完整扫描。若订阅 URL、节点凭据、WebDAV、GitHub Token 或其他密钥曾进入该设备，应从一台可信设备让旧凭据失效并重新签发；分享日志前先制作脱敏副本。完整性无法确认时，从官方来源重新安装系统或客户端，并只恢复确认干净的配置。

如果 2.38.0 以上版本导致某项订阅转换或脚本不再工作，不要为了恢复功能降级到 2.37.1 或更早版本。先关闭 Sub-Store，继续使用已经验证可用的 Clash Party Profile；需要恢复订阅时，从可信服务商重新取得原始链接或导入升级前的干净备份。

只有在新版本、Allow LAN 关闭且监听限于 127.0.0.1 的条件下，才重新开启 Sub-Store 复测。若某个第三方脚本仍必须依赖被限制的旧行为，应停止使用该脚本并联系维护者更新，而不是放宽整个本地 API。

这次风险的核心对象是 Clash Party 启动的 Sub-Store Node 后端，不是 Mihomo 内核，也不是所有名为 Clash 的客户端。后续复核应同时记录 Clash Party 版本、Sub-Store data.version、Allow LAN 状态和实际监听地址。

官方 2.38.0 发布关闭了 #634，2.39.6 是本次检查时的当前稳定版；Clash Party #2134 仍只是用户报告。若上游以后发布新的安全公告、鉴权机制或 Clash Party 整合版本，应以新的官方 Release、提交和说明更新结论。