新的零日漏洞瞄准Meta的AI智能体
安全研究员Patrick Wardle披露了Meta的Muse AI智能体中的一个零日漏洞，并发布了一款名为“not-a-mused”的概念验证工具，用于演示该漏洞的实际效果。根据披露内容，该问题允许设备上已在运行的本地进程重定向原本发送给Muse AI智能体的听写内容，从而有效劫持用户与助手交互所依赖的语音输入通道。
这并非传统意义上的远程攻击。它需要同一台机器上已有其他程序在运行，但这一区别的重要性可能没有看起来那么大。恶意软件、流氓应用或被入侵的后台进程都可能构成利用该漏洞所需的“本地进程”。一旦这一立足点存在，Wardle的概念验证就展示了原本用于某一目的的听写内容如何被拦截或改道，而用户毫无察觉。
听写劫持的工作原理
Muse AI与许多现代AI智能体一样，旨在接收语音输入并快速对其做出响应，无论是起草消息、回答问题还是触发其他操作。这种速度和便利性依赖于助手对为其提供命令的音频管道的信任。Wardle的研究表明，这种信任可以被滥用：本地进程可以将自身插入该管道并重定向听写流量，这意味着用户说出的话可能不会流向他们预期的位置，或者来自其他来源的内容可能在无明显警告的情况下被替换。
实际风险很直接。语音输入通常包含敏感信息，如个人消息、账户详情或用户认为私密的搜索查询。如果本地进程能够悄悄重定向或捕获该听写流，就为窃听或操纵打开了大门，而用户无法实时察觉。名为“not-a-mused”的概念验证工具是专门为演示这一行为而构建的，而非作为攻击工具包使用，但它的存在凸显了一个事实：该漏洞是可验证的，而非理论上的。
为何这符合更广泛的模式
这一披露正值外界日益关注AI智能体在其运行的设备上如何处理权限、信任和后台访问之际。安全研究人员已经指出了一种模式：AI系统因其自身设计的自主性而被拉入攻击链。SentinelOne已记录了四起独立的智能体AI网络攻击事件，表明那些旨在以最少人工监督来规划和执行任务的工具正日益成为攻击者的目标，而不仅仅是工具。
Muse AI听写问题符合这一趋势。随着AI智能体被赋予更多对麦克风、文件和其他敏感输入的直接访问权限，攻击面以用户不总是能明显察觉的方式扩大。这提醒我们，免提听写等便利功能往往伴随着信任假设，而攻击者有动机去测试这些假设。类似的张力也出现在隐私领域的其他角落，包括关于数据收集系统以用户保护之名究竟能合理化多少数据收集的争论，其中功能性与暴露之间的平衡是一个反复出现的主题。
这对你意味着什么
如果你使用Muse AI或任何依赖听写或语音命令的AI助手，这一披露是一个有用的提示，让你思考该助手能访问你设备上的什么内容，以及还有什么其他程序与其一同运行。该漏洞需要本地进程已经存在，因此基本的设备卫生——保持软件更新、避免不受信任的下载、审查哪些应用拥有麦克风或后台访问权限——仍然是你的第一道防线。
同样值得记住的是，像Wardle这样的研究员发布的零日漏洞披露通常会促使厂商迅速调查和修补。关注Muse AI的更新并在可用时及时应用是合理的做法。与此同时，注意你向任何AI智能体口述的敏感信息，尤其是在共享或安全性较低的设备上，是明智的预防措施。
关键要点
Muse AI零日漏洞及时提醒我们，AI智能体尽管便利，却引入了传统应用所没有的新隐私考量。本地进程重定向听写听起来可能是一个狭窄的技术问题，但它指向了一个更大的问题：我们对喂养AI助手的管道有多信任，还有谁可能在监听？
在Meta发布指导或修复之前，用户应定期审查应用权限、保持设备更新，并对向任何AI系统大声说出的内容保持谨慎。随着AI智能体日益融入日常数字生活，以对待任何其他敏感应用的同等审视态度来对待它们对麦克风和个人数据的访问，只是一种良好的实践。
