Meta AI 客服漏洞：20,225 個 Instagram 帳號的驗證缺口

我第一次看到這則事件時，也被標題帶著走了：駭客只對 Meta AI 客服說「這是我的帳號，請把新 email 連上去」，AI 就信了，接著把帳號交出去。

讀完 Meta 提交給緬因州檢察總長的事件通報後，我得修正這個判斷。公開證據能確認的是：AI 輔助的 Instagram 帳號恢復系統有一條後端程式路徑漏做 email 比對。至於語言模型有沒有判斷「這個人就是帳號擁有者」、駭客是否靠話術說服模型，目前沒有公開技術資料可以證明。

這個差別很重要。若把原因寫成「AI 太好騙」，工程團隊可能去調整提示詞或模型；官方通報指出的缺口，卻是每次高權限操作都該執行的身份核對沒有執行。

Meta 官方到底確認了什麼？

Meta 的事件通報把系統稱為 High Touch Support（HTS），是一套 AI 輔助的 Instagram 帳號恢復工具。使用者被鎖在帳號外時，可以要求系統把密碼重設連結寄到 email。

Meta 在通報裡寫得很具體：HTS 工具本身依原先設計運作，但「另一條程式路徑」有 bug，沒有確認使用者提供的 email 是否與該 Instagram 帳號原本綁定的 email 相符。因此，不屬於帳號的信箱也可能收到密碼重設連結。

從這份通報可以確認的最短攻擊鏈是：

有人向 HTS 提交一個未綁定目標帳號的 email。
後端沒有拒絕不相符的 email，反而把密碼重設連結寄過去。
收件者可以重設密碼；如果帳號沒有開啟兩階段驗證，便可能登入帳號。

Meta 表示 5 月 31 日發現問題，當天停用 AI 輔助支援工具、移除有問題的路徑、撤銷相關重設連結，並要求可能受影響的帳號重新驗證。重新上線前，Meta 也承諾修正帳號恢復入口的身份檢查，並檢查其他相似流程。

所以這起事件確實發生在 AI 輔助客服裡，也確實造成帳號接管風險；但目前的第一手證據指向後端驗證缺漏，沒有證明模型把一句自然語言當成身份授權。

20,225 個帳號不等於 20,225 個帳號都被盜

西班牙國家網路安全研究院 INCIBE 的事件整理列出 2026 年 4 月 17 日至 5 月 31 日的事件區間，以及全球 20,225 個潛在受影響帳號。這個數字很大，但「潛在受影響」和「確認遭到接管」不能混用。

Meta 的通報以緬因州 30 名使用者為例，明確把人數稱為上限：這些帳號曾透過該工具重設密碼、沒有開啟 2FA，而且活動看來可能未經授權；其中仍可能包含帳號本人正常使用恢復流程。Meta 也表示，當時不知道有哪些個人資料真的被讀取。

可能被看到的資料則包括聯絡資訊、生日、貼文、私訊、帳號活動、個人檔案與相連帳號。即使最後只有一部分帳號遭接管，風險仍然夠嚴重；沒必要把上限寫成已確認受害人數來增加戲劇性。

歐巴馬、太空部隊與 Sephora 是哪一層證據？

404 Media 的報導引述駭客說法、Telegram 流傳的影片與截圖，描述攻擊者把新 email 交給 Meta AI 客服，並稱這套手法與歐巴馬白宮封存帳號、美國太空部隊一名資深士官長及 Sephora 帳號遭接管的時間相符。

這些材料足以讓記者追查，也能補上官方通報沒有寫出的攻擊現場；它們仍不是 Meta 對個別帳號的技術鑑識結論。比較準確的寫法是「媒體報導將這些高知名度帳號與該手法連結」，不能寫成「Meta 已公開確認這些帳號都被同一漏洞接管」。

同樣地，VPN 偽裝目標所在地、駭客在地下市場轉售帳號等細節，目前來自媒體與攻擊者材料。它們可能是真的，但證據層級和 Meta 的事件通報不同。

2FA 有沒有被繞過？

部分二手文章寫成攻擊者「繞過 2FA」。這和 Meta 給監管機構的說法衝突。

Meta 的通報寫的是：攻擊者取得密碼重設連結後，只有在帳號持有人未啟用 2FA 時，才可能登入帳號。緬因州列入通知的 30 個帳號也都沒有開啟 2FA。除非後續出現事故鑑識或 Meta 更新說法，這裡應以第一手通報為準。

2FA 因而成了這條攻擊鏈的第二道獨立關卡。第一道 email 核對失效後，它仍要求攻擊者提出另一份證明。這不代表 2FA 可以替後端漏掉的驗證收拾所有錯誤，只表示多層防線確實減少了單點失誤的傷害。

AI 在這起事件裡扮演什麼角色？

Meta 在 2026 年 3 月介紹 AI 客服時，用了「Solutions, not just suggestions」這句話。官方產品頁也說 AI 支援可以處理帳號安全與恢復等任務。這顯示 Meta 正讓客服 AI 從回答問題走向執行操作，但不能據此斷定 3 月公告的每項功能就是這次 HTS 的完整架構。

AI 介面仍會擴大需要防守的輸入範圍。使用者不再只能填固定表單，而能用自由文字描述意圖；模型還可能選擇工具、整理參數，再把請求送到後端。這種系統若把模型輸出的帳號、email 或「已驗證」狀態直接當成可信資料，風險會很高。

不過，安全邊界不該放在模型是否聽話。無論前面是 LLM、真人客服或傳統表單，後端在送出密碼重設連結前，都必須獨立確認收件信箱有權為該帳號執行恢復。前端傳來的每個身份聲明，都只能算待驗證輸入。

OWASP 的 Excessive Agency 說明也把重點放在下游系統：授權檢查要由確定性的元件執行，不能指望 LLM 自己判斷何時有權操作。對高影響動作，才視風險加入人工核准；人工不是每次操作都必備的萬靈丹，完整且不可跳過的後端驗證才是底線。

Tool 介面該怎麼畫？

最危險的設計，是讓模型自己提供 username、is_verified 和 new_email，然後由一個 tool 直接完成變更。模型若能填入「已驗證」，那個欄位沒有任何安全價值；模型若能指定任意帳號，後端也失去從登入狀態限制操作範圍的機會。

比較合理的做法，是把身份與帳號從受信任的執行環境注入。模型只負責表達「使用者想變更 email」以及新的信箱值：

@tool
def request_contact_email_change(new_email: str) -> str:
    """建立待核准的信箱變更，不直接修改帳號。"""
    actor = auth.require_principal(tool_context.session_id)
    account = accounts.for_principal(actor)

    intent = changes.create_pending(
        actor_id=actor.id,
        account_id=account.id,
        action="change_contact_email",
        normalized_params={"new_email": normalize_email(new_email)},
    )
    challenge = step_up.issue(
        principal=actor,
        action_hash=intent.action_hash,
        methods=account.allowed_recovery_methods,
        expires_in_minutes=10,
    )
    return render_next_step(challenge)

真正生效則由另一個不交給模型自由呼叫的流程處理：

def commit_contact_email_change(intent_id, signed_approval):
    intent = changes.load(intent_id)
    policy.verify_exact_action(intent, signed_approval)
    policy.require_not_expired(signed_approval)
    policy.require_not_replayed(signed_approval)

    accounts.change_email(
        account_id=intent.account_id,
        new_email=intent.normalized_params["new_email"],
    )
    notifications.send_to_previous_channels(intent.account_id)