What is the confused deputy vulnerability and how did it apply to Meta's HTS system?

A confused deputy attack occurs when a privileged system acts on behalf of a requester without verifying whether the requester is actually authorised to request that action. In Meta's High Touch Support chatbot, the AI had elevated access to trigger password reset emails. When an attacker submitted a recovery request and supplied their own email address, the bot sent the reset link to the attacker's email rather than verifying the email belonged to the account owner. The AI held the 'deputy' privilege; the attacker directed it without authorisation.

Would two-factor authentication have protected against this attack?

Yes, for most attack variants. Accounts protected with two-factor authentication were not compromised in this incident. The attack exploited the password reset flow, which on its own grants access before 2FA is re-enrolled. Accounts with 2FA retained that layer, meaning an attacker who obtained the reset link would still be blocked at authentication. Meta's disclosures confirmed that 2FA-enabled accounts were safe.

What should organisations running AI-assisted support systems do to prevent this class of vulnerability?

The core control is to enforce that any action the AI takes on a user account must be authorised by the verified owner of that account, not the requester presenting the ticket. Specifically: never accept an email address supplied by the requestor as the destination for account recovery tokens — always retrieve the verified email from the account record itself. AI agents with account-management tool access must have authorisation checks baked into the tool layer, not delegated to the AI's judgment.

Incident Report: Meta AI Tool Handed 20,000 Instagram Accounts to Attackers

Q: How were attackers acquiring target accounts and monetising them?

Attackers targeted high-value 'OG' (original gangster) handles — short, memorable usernames registered in Instagram's early days — as well as verified brand accounts. Compromised accounts were sold on dark web marketplaces, with premium OG handles reportedly fetching upward of $500,000. Business accounts with large follower counts commanded $1,000–$10,000 depending on niche and engagement.

Meta disclosed on June 5–6, 2026 in a filing with the Maine Attorney General’s office that approximately 20,225 Instagram accounts were compromised between April 17 and May 31, 2026. The root cause was a confused deputy vulnerability in the company’s High Touch Support (HTS) system — an AI-assisted account recovery tool designed for high-value creator and business accounts. An attacker could supply their own email address during an account recovery request and receive a password reset link for an account they did not own.

Incident Summary

Field	Detail
Incident type	Confused deputy vulnerability in AI account recovery system
Affected system	Meta High Touch Support (HTS) AI chatbot
Attack vector	Account recovery flow — attacker-supplied email accepted without ownership verification
Accounts compromised	20,225 Instagram accounts
Attack window	April 17, 2026 – May 31, 2026 (45 days)
Patch date	May 29, 2026
Discovery date	May 31, 2026
Disclosure date	June 5–6, 2026 (Maine AG filing)
2FA-protected accounts	Not affected

Attack Mechanism: The Confused Deputy Pattern

Meta’s High Touch Support system is an AI-assisted support workflow built for high-value Instagram accounts — verified creators, brands, and business accounts — to receive accelerated help with access issues. The system had elevated permissions to initiate account recovery actions on behalf of support agents, including triggering password reset emails.

The vulnerability was in how the system handled the email address used for recovery link delivery. When a support request was submitted, the code path accepted the email address supplied in the request rather than retrieving the verified contact email from the account record itself. The attacker’s flow was straightforward:

Submit an account recovery request for a target Instagram account
Supply the attacker’s own email address as the recovery contact
Receive the password reset link at the attacker’s email
Use the link to reset the password and take over the account
Change account credentials, email, and 2FA settings before the legitimate owner can recover

This is a textbook confused deputy attack. The HTS system was the “deputy” — it held elevated privilege to initiate account actions. The attacker was the “requester” — unauthorised, but the system acted on their behalf anyway because the authorisation check was missing. The AI had the capability; the attacker had the intent; the missing control was ownership verification.

Meta confirmed the vulnerability was a code error in the HTS system, not a compromise of Meta’s broader infrastructure or a social engineering attack against support agents.

Scope and Victims

Meta’s Maine AG filing placed the affected account count at 20,225. Among confirmed victims:

The Obama White House account — the former administration’s official Instagram handle
Sephora — the global cosmetics retailer’s brand account
Jane Manchun Wong — prominent security researcher and reverse engineer, known for discovering unreleased app features
US Space Force Chief Master Sergeant John Bentivegna — the senior enlisted advisor to the Chief of Space Operations

High-profile victims became public when their accounts were observed posting unauthorised content or when the owners disclosed the breach directly. The full list of 20,225 accounts spans a mix of large creator accounts, brand accounts, and high-value personal handles.

The 45-day exploitation window — from April 17 to Meta’s patch on May 29 — suggests the vulnerability was being actively exploited before Meta became aware of it. The gap between patching (May 29) and formal discovery acknowledgment (May 31) implies the investigation confirmed active exploitation that had already been ongoing.

Monetisation and Underground Market

Compromised accounts were sold on dark web marketplaces. The primary target categories were:

OG handles — short, memorable usernames (typically two to five characters) registered during Instagram’s early years. Scarcity and brand value make these highly sought after. Prices on underground markets reportedly reached $500,000 for premium handles.

Verified brand and creator accounts — accounts with large follower counts and verification status, targeted for scam campaigns, product promotion fraud, and credential resale. These commanded $1,000–$10,000 depending on follower count and niche.

Business accounts — accounts connected to business pages, ad accounts, and payment methods, offering secondary fraud opportunities beyond the social media account itself.

What Protected Accounts

Meta confirmed that accounts with two-factor authentication enabled were not compromised. The attack exploited the password reset flow, which on its own is sufficient to lock out an account owner — but only if 2FA is not in place. An attacker who received a reset link for a 2FA-protected account would be blocked at the authentication stage after resetting the password.

This is a meaningful boundary condition: 2FA protected users from this specific attack vector. It does not mean accounts with 2FA are broadly immune to AI-assisted support exploitation — a different vulnerability in the same system could bypass 2FA if, for example, the AI had permissions to modify 2FA settings directly.

Root Cause Analysis

The vulnerability reduces to two compounding failures:

1. Missing ownership verification on the recovery email The HTS system should have retrieved the account’s registered email address from Meta’s own account record and used that as the exclusive delivery destination. Instead, it accepted the email supplied in the support request. There is no scenario where accepting an externally-provided email for a password reset is safe — this is a first-principles error in the code path.

2. Excessive AI agent tool permissions without compensating controls The HTS system had elevated access to initiate account recovery actions. When an AI agent or automated system holds privileges to take consequential actions on user accounts, every action must be authorised against the verified identity of the account owner — not the identity of the requester. The AI’s elevated capability existed without a corresponding authorisation gate.

Neither failure alone would be surprising in isolation. Together, they created a complete account takeover path.

Remediation and Response

Meta patched the vulnerability on May 29, 2026, two days before the company’s formal acknowledgment of exploitation on May 31. The Maine AG filing on June 5–6 represented the formal legal disclosure trigger.

Meta’s disclosed remediation steps:

Fixed the code path to use the account’s verified email address for all recovery link delivery
Reviewed HTS system tool permissions and tightened account-action authorisation
Notified affected account holders with guidance on account recovery and 2FA enrollment

Meta did not publicly disclose whether the 45-day window was the full exploitation period or whether earlier exploitation occurred but wasn’t detected.

Defensive Implications for Organisations Running AI Support Systems

This incident provides a concrete case study for any organisation that has deployed AI-assisted support workflows with account management capabilities.

Authorise at the tool layer, not the AI layer The AI should never be the sole authorisation boundary for account actions. Authorisation checks — “is this requester allowed to take this action on this account?” — must be enforced in the tool or API layer, independently of the AI’s judgment. An AI that believes it is helping a legitimate user is still acting correctly from its own perspective; the failure must be caught before the action executes.

Never accept identity claims from requesters for consequential actions Recovery contact information, email addresses, phone numbers, and authentication tokens must always be retrieved from the authoritative account record — never accepted from the party submitting the request. This applies to AI systems, support agents, and automated scripts equally.

Scope AI tool permissions to the minimum required An AI that can read account information does not need to initiate recovery flows. An AI that can initiate recovery flows does not need to be able to supply the destination email. Decompose permissions granularly, and add authorisation checks at each privilege boundary.

Audit AI support flows before deployment with adversarial test cases “What happens if I supply my own email in this field?” is a basic adversarial test case. Red-team exercises for AI support systems should include confused deputy scenarios — where the attacker attempts to direct the AI’s elevated capabilities against targets the attacker does not own.

Treat 2FA as a last line of defence, not a substitute for authorisation controls 2FA prevented compromise in this incident for accounts that had it enabled. But 2FA is not a substitute for correct authorisation in the layers above it. If the AI had had permissions to modify 2FA settings, the protection would not have held.

Timeline

Date	Event
April 17, 2026	First confirmed account compromise via HTS vulnerability
May 29, 2026	Meta patches the vulnerable code path
May 31, 2026	Meta formally identifies and acknowledges active exploitation
June 5–6, 2026	Maine Attorney General notification filed; 20,225 affected accounts disclosed