Meta 新推出的 AI 助手 Muse 在面向公众开放后不久，就暴露出一处严重的零日安全漏洞。据 WIRED 报道（原作者 Dan Goodin，Ars Technica），该漏洞允许攻击者在受害者搭载 macOS 的 Mac 电脑上“为所欲为”——从读取本地文件、窃取账号凭证，到安装持久化后门，几乎不受任何限制。Meta 表示已针对该漏洞发布修复程序，但这起事件再次把一个老问题推到台前：当我们将系统权限交给一个 AI 助手时，我们究竟交出了什么？
漏洞的关键：AI 助手有了“手和脚”
过去十年，聊天机器人的主要风险是“说错话”——生成偏见内容、泄露训练数据、被提示词攻击诱导越狱。而新一代 AI 助手被赋予了执行能力：读写文件、操作终端、调用本地 API、代替用户点击界面。Muse 正是这一类产品，它被设计成能够理解自然语言指令，并直接在操作系统层面替用户完成任务。
便利的背后是权限。安全研究者长期警告，一旦这类“代理式”（agentic）AI 成为攻击面，漏洞的危害等级就会从“信息泄露”直接跳到“远程代码执行”。Muse 的零日漏洞正是如此：攻击者无需物理接触设备，就可能借助助手在指令解析或权限校验上的缺陷绕过沙箱限制，取得与合法用户同等的控制权。
Meta 表示已针对该零日漏洞发布修复，该漏洞本可让攻击者在受害者的 Mac 上“为所欲为”。
为什么 AI 助手成了新的高危攻击面
传统桌面软件的权限边界相对清晰：浏览器不该读写你的文稿目录，图片编辑器不该联网上传通讯录。但 AI 助手的设计初衷恰恰是打破这些边界——它需要访问你的文件才能总结文档，需要调用系统接口才能帮你整理日程，需要连接云端模型才能理解指令。于是，一个产品同时握有本地权限、网络通道和自然语言入口，三者叠加，构成了攻击者梦寐以求的组合。
更棘手的是“提示注入”（prompt injection）这一新型攻击手法。攻击者不必直接攻破助手本身，只要把恶意指令藏在助手会读取的内容里——一封邮件、一个网页、一份 PDF——就可能诱导助手执行本不该执行的操作。当助手拥有系统级权限时，这类攻击的后果被急剧放大。Muse 的漏洞虽由 Meta 定性为零日缺陷，但它提醒我们：AI 助手的安全模型，远未成熟。
修复之后的三个真问题
第一，响应速度与披露节奏。Meta 快速发布修复值得肯定，但零日漏洞意味着在补丁推出之前，攻击窗口已经真实存在。用户往往在事后才知道自己曾处于风险之中。
第二，权限最小化原则被忽视。行业普遍存在的问题是，AI 助手在安装时索要的权限过于宽泛，而用户早已习惯一路“同意”。如果助手只需要读取指定文件夹，就不应获得整个磁盘的访问权；如果任务不需要联网，就不该默认保持外联。
第三，责任归属。当 AI 助手被攻破并造成损失，责任在模型提供方、操作系统厂商，还是用户自己？目前在多数司法辖区，这一链条仍不清晰，而模糊的责任划分往往会削弱厂商加固安全的动力。
编者按：AI 助手的“能力红利”与“安全负债”
Muse 事件不应被简单看作一次孤立的产品事故，而是整个行业进入“AI 代理时代”后必然遭遇的结构性风险。过去两年，几乎所有大厂都在把助手从“对话框”推向“操作系统执行层”——因为这确实能创造真实的用户价值。但能力与风险从来是同一枚硬币的两面：你给助手多少权限，就等于给潜在攻击者多少权限。
对于普通用户，现实的建议是：谨慎授予 AI 助手系统级权限，优先使用按需授权的沙箱模式，及时安装安全更新，并对“让助手自动处理一切”保持一份克制。对于厂商，真正的考验不是危机公关的速度，而是能否在产品设计的第一天，就把“最小权限”和“默认安全”写进架构。否则，今天被修复的零日漏洞，只会是明天另一场事故的预演。
本文编译自WIRED
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接