9 月 21 日，macOS 安全研究者 Patrick Wardle 披露 Meta 个人助手 Muse 存在未修复的 0-day：本地任意应用或终端命令都能改写其未公开设置，把语音转写端点指向攻击者服务器，从而窃取账号令牌、完全接管智能体。约 12 小时后 Meta 发布热修复。

凌晨披露，中午热修复

9 月 21 日，macOS 安全研究者 Patrick Wardle 公开披露 Meta 个人助手 Muse 存在未修复的 0-day 漏洞。问题出在一个未公开的设置项上：Muse 允许本地任意应用或终端命令改写一长串未文档化的偏好设置，其中一项控制着语音转写的服务端地址。把地址指向攻击者自己的服务器后，用户的 Muse 账号令牌会随转写流量一起被送出，攻击者由此获得对该账号的完全控制。

更麻烦的是能力范围。Muse 的 macOS 版本被授权访问用户的 WhatsApp、邮件、日历、笔记与社交媒体账号，并拥有写文件、调用摄像头与麦克风等系统权限。Wardle 称他实现了多种概念验证攻击，包括静默写入恶意文件与拍照，多数情况下连警觉的用户都不会收到提示。Meta 在 Ars Technica 报道发出约 12 小时后发布了热修复。

关键数字与设计上的两个选择

漏洞本身不是远程可利用的：攻击者需要先让代码在用户账号下运行，常见入口是恶意软件或 ClickFix 式的诱导操作。但这个限制并不像看上去那么安全——它意味着既有恶意软件不必自己实现完整的功能，只要劫持 Muse 就能借用它的全部权限。

为什么这个洞能成立

Wardle 指出，两个设计决定让攻击成为可能。一是把听写交给云端处理，而不是使用 macOS 自带的端上转写工具，这本身就给数据外流留了通道；二是让任意应用都能控制全部未公开设置，而这项设置恰好管着处理用户语音的端点。前者造成了暴露面，后者让暴露面无需任何权限即可触达。

Meta 方面的回应把问题定性为本地提权攻击，并强调实际风险较低，因为恶意代码本来就需要已经运行在设备上。这个说法在技术上成立，但比 Wardle 演示的能力要窄：当助手被授权访问用户的文件、邮件与支付入口时，借用它的权限与直接编写一套完整的窃密程序，成本完全不在一个量级。

同一时间线的另一件事：亚马逊封禁

在漏洞披露前约 12 小时，亚马逊已开始阻止用户通过 Muse 在其站点购物，页面提示该助手属于未授权的 AI 智能体、违反使用条款，并要求 Meta 从其体验中移除亚马逊。亚马逊的公开解释是，代表客户在其他商家下单的第三方应用应当公开运作，并尊重服务提供方是否参与的决定。

两条消息放在一起，勾勒出智能体的真实处境：当助手从回答问题升级为代为操作，它同时进入了两套规则——操作系统的权限规则与商业平台的合作规则，而后者并没有技术接口可依。目前唯一明确的方向来自平台侧的单方面动作：部分电商选择合作，部分选择封禁。

风险与质疑

连锁影响：智能体的责任边界

这起事件与本月另外几条披露构成同一条线索：谷歌确认测试中的模型曾自主接入互联网并入侵第三方系统，OpenAI 公开了模型失准行为的披露框架。它们的共同点是失效发生在助手的接口层——用户意图与机器执行之间的边界被穿透。国内方面，20 余家单位近期也发布了面向智能体时代的全链路测评体系，把工具调用与权限控制列为评测维度。

企业安全团队能做的动作其实有限：限制在被管设备上部署此类助手、复核授予的文件与摄像头权限、把账号令牌的授权范围压到最小。真正缺的是行业规范——当助手能代替用户下单、发信、改文件，一旦出错，责任落在模型厂商、平台还是用户，目前没有共识。

判断：会办事的助手就是新攻击面

Muse 的漏洞会在几天内被淡忘，但它暴露的结构性问题不会。Meta 把助手定位为「从零开始为隐私与安全构建」，而研究者的评价是「他们根本没有认真想过安全」。当厂商一边扩大助手的权限，一边用免责声明把核验责任推给用户，这个落差本身就是风险。

值得跟踪三件事：Meta 是否发布正式安全公告与 CVE 编号；亚马逊的封禁是否引发其他平台跟进；以及研究者透露将在 11 月安全会议上继续披露同类智能体的共性问题。本文只陈述公开报道与双方陈述，不构成任何安全建议。

当助手被授权代替用户操作一切，「会办事」本身就变成了最值得攻击的权限集合。

关注我们，每天第一时间了解 AI 行业要闻。