8月18日消息,据 RuntimeWire 报道,其对 Kimi Work Windows 桌面客户端(3.1.5 版)的逆向分析发现:用户提交反馈时,客户端会自动打包上传最近更新的 5 个智能体会话的原始记录,反馈表单既不列出这些附件,也不提供选择或取消上传的选项。月之暗面未就此公开回应。 爆料说了什么
RuntimeWire 的报道包含三个可分离的主张。第一,触发机制:提交反馈会并行执行诊断日志上传与「原始记录」上传,后者从所有 Work 会话中按更新时间排序取出最近 5 个,分别打包上传。第二,无披露:反馈界面只提示填写描述与添加图片,不显示这 5 个会话,用户无法在提交前审查将上传的内容。第三,与反馈无关:测试者从插件页面提交了一条无害测试反馈,客户端仍按同一流程抓取最近 5 个会话,与正在反馈的问题没有对应关系。
其中前两项是这次爆料的争议核心:反馈场景用户默认「只提交了我说的问题」,实际夹带了用户未被告知的工作会话数据。
技术证据能证明什么
报道给出的是可复现的技术证据,而不是推测。静态追踪显示,反馈按钮的调用链路经过 renderer 到 Electron IPC,再到 ZIP 生成与两个上传端点(/file/upload_simple 与 /user/feedback);主进程对所有会话按 updatedAt 排序后取前 5 个。运行时验证中,测试者用 Windows 防火墙阻断客户端外联后提交反馈,日志记录到 5 个不同会话 ID 的上传尝试,主进程日志显示「0/5 archives uploaded」——上传逻辑确实在生产环境执行。后续有开发者在 Hacker News 复现了该发现,国内蓝点网等媒体亦做了转载。
数据范围上,据 RuntimeWire 分析,每个会话的原始记录包含模型请求、工具定义与调用、MCP 工具信息以及官方文档称为「完整通信记录」的 wire 文件,单会话压缩包上限约 8 MB、5 个会话合计上限约 40 MB。过滤逻辑有限:仅剔除大体积 Base64 与超长字符串,密码、API Key、访问令牌、私有源码等普通尺寸的敏感文本会原样保留。作为对照,Kimi CLI 的会话导出有独立的显式流程与「文件可能含代码、命令输出和文件路径」的警告,而反馈流程没有任何类似提示。
替代解释与证据缺口
证据支持「机制存在」,但有几处仍无法确认。一是覆盖范围:分析对象是 Windows 版 3.1.5 与随附的 Daimon 0.5.49 组件,其他平台与版本是否相同尚无公开验证。二是服务器端行为:上传到月之暗面服务器后的存储、访问与使用情况未知,报道没有证据表明服务器端会二次脱敏。三是上线时点与设计意图:该行为何时加入、为何未披露,均无官方说明,也不存在可用来推断动机的公开材料。四是官方回应:截至 8 月 18 日,月之暗面没有发布任何声明。
有限结论
目前能确认的是,Kimi Work 的反馈流程确实会打包最近 5 个会话并上传,且界面不披露、不可选;这与报道的技术证据一致,并被开发者复现。不能确认的是服务器端如何对待这些数据,以及这是否为有意设计——动机问题没有证据,不应推断。
RuntimeWire 明确指出未发现可被远程利用的路径,这是「收集范围与披露」问题,不是安全漏洞。但对用户而言影响是实际的——Kimi Work 处理私有文件、源码与 shell 输出,反馈一个 Bug 可能把无关工作会话一并带出。在官方澄清之前,介意数据上传的用户可以谨慎使用反馈功能,或改用其他渠道提交问题;同时等待月之暗面说明该行为覆盖的版本、数据保留时间与访问控制。