你弄伤我的鳞片了
@xinshou
一次教科书级的负责任披露闭环。研究者 Patrick Wardle 先发出警告："先别装——这能被轻易变成终极后门"，指出 Muse 这个要管理你整台 Mac 的 AI 助手存在严重 0 级漏洞，本地恶意程序能悄悄劫持它；紧接着，应用方当天发布热修复并逐条把机制讲清楚。
攻击面（本地提权，非远程）：要利用它，恶意代码必须已经在你机器上、以你的用户身份运行——效果是"把已存在的恶意软件扩权成 Muse 的 agent"。机制拆开看：Muse 的听写由服务端语音模型驱动，应用里带着一个开发调试用的"端点可重定向"设置，存在本地偏好文件里——而 macOS 允许同一用户下的任何程序改这些设置；改掉端点后，攻击者可以代理听写请求、截获应用驱动 agent 所用的访问令牌。
官方同时划清了边界：不涉及 Muse 的服务器，也不涉及隔离 agent 任务的 Secure VM。
修复与激励：热修复从生产构建中彻底移除该设置——漏洞直接封死；官方表态连"已公开利用代码"的报告都会严肃对待，并给出 bug bounty 通道、此类问题赏金最高 30 万美元（链接见文末）。
披露的时间线也值得记：研究者是先公开警告、并附上演示代码，官方随后响应——即便报告带着"已公开的利用代码"，回应依然逐条给机制、给边界、给修复。这种"研究者敢发、厂商敢认"的配合，比任何漏洞赏金广告都更能说明一家公司对安全的态度。
边界设计上有一个清晰的教训：Muse 的服务端与 Secure VM 隔离做得没毛病，被攻破的却是本地一个开发期的可重定向设置——云端隔离做得再漂亮，本地的一个调试口就能让整条链破功。隔离的强度取决于最弱的一环，而最弱的往往是"为了方便而留的那扇门"。
顺带给高权限 AI 助手的使用者一份自检清单：装之前问三件事——①它要哪些系统权限（文件、辅助功能、麦克风）；②这些配置能不能被同用户下的其他程序改掉；③厂商对安全报告的态度（有没有赏金、敢不敢公开机制）。另外别忘了前提条件：这类攻击需要机器上先有恶意代码——把恶意软件挡在门外的常规防护，依然是所有上层安全的地基。
我的看法：这条与今晚另一篇（真车实验里"安全边界不能靠模型自觉"）互为印证，但它给出了正面样板——权限越大的 AI 助手，本地攻击面越危险，而响应可以做得漂亮。三个可迁移的教训：其一，调试开关绝不能进生产构建——他们热修复的头一件事就是删掉这个端点设置；其二，本地提权的真正卖点是"令牌→接管助理"——已有恶意软件借 agent 获得持久化与身份，这比单纯 RCE 更难察觉；其三，透明响应本身就是安全资产——机制、影响面、修复路径、赏金四样全摆出来，比"我们非常重视"四个字可信一万倍。厂商给出的"风险较低"属其口径，研究者原文含演示细节、本篇不复述操作。
赏金通道：bugbounty.meta.com
