2026-06-11

两万多个 Instagram 账号被劫持：AI 客服成了绕过鉴权的新越权通道

攻击者只用一句「把验证码发到这个邮箱」，就让 Meta 的 AI 客服替没开两步验证的账号重置了密码。当 AI 接进账号系统，它就成了传统鉴权之外的一道新越权入口。

概述

Meta 正在通知至少 20,225 名用户，他们的 Instagram 账号在一场持续数月的攻击中被劫持。根据它向缅因州总检察长办公室提交的数据泄露通知，这场攻击大约从 4 月 17 日开始，一直持续到本周 Meta 把出事的 AI 客服关停为止。手法简单得令人不安：攻击者不需要破解密码，不需要钓鱼链接，只要去跟 Meta 的 AI 账号恢复客服说「把验证码发到这个邮箱」，客服就照做了，前提是目标账号没开两步验证。

这不是一次「AI 出错答错了问题」的事故，而是一次「AI 被当成办事窗口、却没有窗口该有的核验」的事故。chatbot 本身按设计正常工作，真正的漏洞在它背后那条独立的代码路径上：系统没有去核对发起重置的人填的邮箱，是否就是账号在册的那个邮箱。AI 在这里扮演的角色，是把一个本该被严格鉴权拦住的高危操作包装成一句自然语言请求。这正是这件事的判断核心。把 AI 接进账号与权限系统，等于在传统登录鉴权之外又开了一条没人盯着的越权通道。

发生了什么

按照报道还原的链条，攻击者面对的是 Meta 的「AI 辅助账号恢复系统」。正常的账号恢复要求把重置链接发到账号在册的邮箱，以此证明发起人确实控制着这个账号。但攻击者发现，只要在跟客服交互时提供一个自己控制的、与账号毫无关系的邮箱，系统就会把密码重置链接发到那个陌生邮箱去，而不是拒绝请求。拿到链接，攻击者就能像真正的账号主人一样重置密码、接管账号。

Meta 在通知里对这个机制说得相当直白：工具本身「正常工作、按预期运转」，但「由于一条独立代码路径上的 bug，系统没有正确核验请求重置密码者所提供的邮箱，是否与该用户 Instagram 账号关联的邮箱一致」。结果就是，当有人提供一个此前从未与账号关联的邮箱时，系统「错误地把重置链接发到了这个未关联邮箱，而不是拒绝请求」。这段话其实承认了一件要害的事：核验逻辑和办事逻辑被拆在了两处，AI 这条新路径绕过了原本应该挡在前面的那道核验。

受影响的范围不小。Meta 通知的 20,225 人里包括缅因州的 30 人；被接管的账号让攻击者能拿到联系方式、出生日期、个人资料，还能访问对方的帖子、私信和账号活动记录。一个关键的限定条件是：只有没开两步验证的账号会中招。两步验证在这里之所以能挡住，不是因为它修好了那条出问题的代码路径，而是因为它在重置流程里又加了一道独立的、AI 绕不过去的核验。这个细节本身就是判断：当主鉴权路径可能被旁路绕开时，一道独立的第二因子就是把损失从「全量」压到「部分」的那道闸。

为何重要

把这件事放进更大的图景里看：过去一年，几乎每家面向消费者的大公司都在把 AI 客服、AI 助手接进自己的账号、订单、客服工单系统，理由是降本和体验。Meta 这次踩的坑不是它独有的技术失误，而是这一整波接入方式里普遍存在的结构性盲点：大家把 AI 当成「更聪明的前端」，却没把它当成一个会被诱导、需要被鉴权约束的执行者。

传统的越权防护假设攻击面是表单、API、登录接口这些结构化入口，防御者很清楚每个字段该校验什么。但自然语言客服把入口变成了一段对话，攻击者不再需要构造请求参数，只需要「开口要」。当这段对话的背后又连着能真正改密码、改邮箱、退款、改地址的执行能力时，AI 就成了一个新的、语义层面的越权入口。它的危险在于：传统的输入校验是针对字段的，而对话式请求往往直接被当成「用户的真实意图」送进了执行逻辑，中间少了那道「你有没有权限做这件事」的硬核验。

还有一层时间维度的判断。这场攻击从 4 月持续到 6 月，跨度数月才被发现并处置。对话式接口天然难审计：一次正常的客服对话和一次恶意诱导，在日志里可能长得几乎一样。这意味着 AI 越权通道不仅更容易被打开，也更难被及时发现。对建设者来说，这条通道一旦开错，暴露窗口可能以月计。

对建设者的影响

第一条，也是最该刻进脑子里的：把 LLM 的所有输入和输出都当成不可信。用户对 chatbot 说的话不可信，这本是常识；更要紧的是，LLM 自己生成的、要去触发某个动作的那段决策同样不可信。Meta 的问题不在于 AI 答错了话，而在于 AI 的输出被直接接到了「发送重置链接」这个动作上，中间没有一道独立的权限核验。正确的姿势是：AI 可以理解意图、可以引导流程，但真正执行高危操作的那一步，必须由 AI 之外的、确定性的鉴权逻辑来放行。

第二条，隔离权限，按最小权限给 AI 接执行能力。问问自己：你的 AI 客服能直接调用哪些有副作用的接口？改密码、改绑定邮箱、退款、导出数据，这些都属于高危操作，不该直接挂在对话 agent 的工具列表里随便调。更安全的做法是让 AI 只能发起一个「请求」，请求是否被执行，由一套独立的、不读 AI 上下文的鉴权服务来判定。这正是本案里两步验证扮演的角色：它不在 AI 那条路径上，所以 AI 被诱导也绕不过它。

第三条，高危操作必须有人审或强核验，不能让 AI 一句话办成。账号接管、资金流动、权限变更这类不可逆或高影响的操作，要么走人工复核，要么强制走一道 AI 无法代答的独立验证（第二因子、带外确认、回到账号在册渠道）。本案里 Meta 事后给受影响用户的指引正是「通过安全、已验证的渠道重新认证」，这恰恰说明可信的核验必须发生在 AI 这条便捷通道之外。把便捷留给 AI，把放行权留给独立鉴权，这两件事要分开。

第四条，把对话接口纳入安全审计和监控。既然对话式越权更难从日志里看出来，就得专门为它建监控：盯住那些「AI 触发了高危动作」的事件，对异常模式（同一来源短时间内大量发起重置、提供的邮箱与在册邮箱不匹配却仍被放行）设告警。本案暴露窗口长达数月，很大程度上就是因为没有这层针对 AI 执行路径的可观测性。

该忽略什么

不必把这件事读成「AI 客服不能用」或「大模型天生不安全」。漏洞的根因不是模型幻觉，不是提示注入的某种花哨变体，而是一条独立代码路径上缺了最基本的邮箱归属核验。这是一个传统的鉴权疏漏，只不过被一个 AI 入口放大并变得更易触达。把锅全甩给「AI 不可靠」，反而会让人忽略真正该补的那道确定性核验。

也不必纠结于「攻击者具体说了哪句魔法咒语」。本案的教训不在话术，而在架构：只要执行高危操作的那一步缺了独立鉴权，攻击者用什么措辞诱导都只是细节。同样，不必被「数千」「两万」这些数字本身吓住而去比较谁家泄露更大。规模是结果，结构性的越权通道才是原因。建设者要修的是后者。

技术要点

把这次事故抽象成一句可复用的原则：AI 接入点应被建模为一个不可信的、低权限的请求发起方，而不是一个可信的执行者。具体落地有三个分层。其一，意图层（AI）与执行层（确定性服务）解耦：AI 产出的是「用户想重置密码」这样的结构化意图，执行层独立地、不依赖 AI 上下文地去核验「这个请求人是否有权对这个账号做这件事」。其二，把核验绑定在不可被旁路的因子上。本案里两步验证之所以有效，正因为它是 AI 这条路径之外的独立锚点；账号在册邮箱、设备、第二因子都应被当成这样的锚点，且高危操作的放行必须强制命中至少一个。其三，为 AI 的每一次工具调用留下结构化审计日志，记录「谁、对哪个账号、发起了什么副作用动作、命中了哪些核验」，让数月级别的暴露窗口在监控里现形为分钟级别的告警。

来源

无官方一手源；本文基于可靠二手报道（具名媒体、交叉印证）写成。