Meta Muse macOS 客户端被曝零日漏洞，可绕过苹果权限框架

这起事件最值得追问的地方，不在于漏洞是否存在——Wardle 已公开披露并给出演示——而在于 Meta 与安全社区对同一技术事实给出了两套截然不同的定性。Meta 超级智能实验室的 David Singleton 将该问题描述为一种需要事先具备代码执行能力的本地配置问题，公司据此将其视为内部配置缺陷，没有走正式的 CVE 编号分配流程。由于 Meta 未发布正式安全公告、也未与 CVE 编号授权机构协调，该漏洞目前没有正式 CVE 编号。

安全社区不认同这一说法。他们指出，利用 ClickFix 等社会工程诱饵即可轻易获得初始访问权限，而绕过苹果的“透明度、同意与控制”（TCC）框架历来十分复杂。换言之，双方对“需要事先具备代码执行能力”这一前提的获取难度判断不同：Meta 把它当作降低严重性的理由，社区则把它当作几乎不构成门槛的起点。这一分歧目前没有独立结论。

漏洞的技术起点是一个名为 endo_voyager_dictation_endpoint 的未公开配置首选项键。正常运行时，该参数用于指定接收语音听写音频并返回转录结果的云端服务器端点。问题在于，在 macOS 上以非特权用户身份运行的本地进程和任意脚本，无需管理员权限、也不触发操作系统授权提示，就能覆盖这一配置值。

一旦该值被改写，攻击者只需修改这一设置，就能悄无声息地把助手发出的听写流量重定向到其直接控制的服务器。当用户启用听写功能时，桌面客户端会把原始麦克风音频以及与受害者 Muse 账户关联的有效身份验证令牌发送至配置的端点。因此该漏洞同时危及输入内容的机密性和账户凭据——这不是一次单纯的窃听，而是凭据层面的失守。

Wardle 进一步演示了攻击者如何运行代理服务器，在捕获身份验证令牌和音频数据的同时把正常流量无缝转发回 Meta 服务器以避免被发现。这种“边偷边转发”的做法意味着受害者与 Meta 两侧都难以从服务异常中察觉中间人存在。

该漏洞在技术层面的重要性，在于它会放大访问权限并侵蚀平台的信任边界。macOS 依靠“透明度、同意与控制”（TCC）框架限制应用访问硬件外设、文件、通讯录和日历。由于 Muse 是一种能够与应用程序、日历、电子邮件和文件交互的智能体，用户通常会授予它广泛的系统权限。

Wardle 指出，该漏洞使恶意行为者无需开发复杂的独立信息窃取恶意软件，只需操纵这一智能体，就能有效地把经过签名、受到信任的助手变成攻击面。这是本次事件最具结构性的含义：攻击者不必攻破 TCC，而是借用用户已经授予助手的权限“借道”通过。

在获得有效会话凭据并直接控制命令管道后，攻击者还可实施提示词注入，在语音请求中附加隐藏指令，迫使助手在后台执行窃取本地文档或 WhatsApp 消息记录等未经授权的任务。Wardle 发布了一个名为 not-a-mused 的概念验证漏洞利用程序，演示如何通过遭到入侵的智能体执行大量命令。需要说明的是，提示词注入这条路径属于 Wardle 演示的攻击链，其实际可利用性未获第三方验证。

漏洞公开披露后，Meta 为 macOS 版 Muse 应用部署了热修复，从生产客户端构建中移除这一内部调试首选项设置，从而阻止本地修改听写服务器的目标地址。工程团队的处理方式是悄然从生产构建中移除内部调试首选项键，而不是发布正式安全公告。

这一修复方式与 Meta 的定性是一致的：如果问题被定义为内部配置缺陷，那么移除配置项就是自然收尾。但从外部视角看，热修复是否完全消除风险、是否存在其他类似可被本地覆盖的调试首选项，来源并未说明。该漏洞仅涉及 Meta Muse 的 macOS 桌面客户端，不涉及其他平台。

Meta 首席执行官马克·扎克伯格曾声称这款自主式人工智能助手从一开始便以隐私和安全为基础打造。本次披露的技术事实——非特权本地进程可改写端点、音频与账户令牌可被静默截获——与这一公开表述之间存在明显张力。

一名前 Meta 人工智能安全工程经理表达了类似的架构层面担忧，并表示由于深度集成所固有的风险，自己不会使用这款软件。需要指出的是，来源未提供该前经理可核实的姓名或具体出处，这一说法应视为来源转述而非已核实事实。

在 Hacker News 和 Reddit 上更广泛的工程讨论中，观察人士指出，Meta 将设备跨端同步、完整磁盘权限、音频流和私人聊天记录集中到一个未受沙箱限制、经过签名且调试端点可修改的智能体中，实际上为普通恶意软件提供了一条几乎不费力便可绕过平台保护机制、同时不触发运行告警的通道。这属于社区层面的判断，而非经独立验证的结论。

此次披露发生在亚马逊以不符合自动化智能体访问政策为由，禁止 Muse 访问其购物平台后不久。来源仅称两者“发生后不久”，并未建立直接关联，因此不应把亚马逊的封禁解读为本次漏洞披露的前因或后果。

把这两件事放在一起看，更稳妥的读法是：在很短的时间窗口内，Muse 这一产品形态先后在平台准入与本地安全边界两个方向遭遇质疑。前者是平台方的政策判断，后者是安全研究者的技术披露，二者性质不同，不宜混为一谈。

第一，该漏洞是否会被正式分配 CVE 编号、是否会有官方安全公告，尚不明确。Meta 未走正式流程这一事实本身，意味着外部无法通过标准渠道追踪其状态。

第二，Meta 将其定性为“内部配置缺陷”而非安全漏洞，与安全社区的判断存在分歧，孰是孰非未有独立结论。这一分歧的核心在于对“初始代码执行能力获取难度”的评估，而双方都未提供可独立核验的量化依据。

第三，热修复是否完全消除风险、是否存在其他类似可被本地覆盖的调试首选项，来源未说明。此外，所有事实均来自单一来源 InfoQ 的报道，缺少 Meta 官方公告或 CVE 记录等第一方佐证，读者在采信具体技术细节时应保留这一限度。