How Hackers Used Meta's Own AI to Hijack Instagram Accounts: A Technical Breakdown

On the weekend of May 31 – June 1, 2026, a wave of high-profile Instagram account takeovers made headlines. The Obama White House account was defaced with pro-Iranian imagery. The Chief Master Sergeant of Space Force lost his account. Sephora's brand page was compromised. None of these attacks involved a zero-day exploit, a phishing link, or a single line of malware. The attacker's only tool was Meta's own AI support chatbot — and a VPN.

This post is a full technical breakdown of what happened, why it worked, and what it reveals about the structural risks of deploying AI agents with privileged account access.

Background: Meta's AI support expansion

In March 2026, Meta announced that it was deploying AI-powered support across all Facebook and Instagram accounts. The system was positioned as an upgrade: faster resolutions, fewer tickets, "solutions, not just suggestions." Critically, the AI agent was granted the ability to perform account management actions — including adding recovery email addresses and triggering password resets — without requiring a human reviewer.

This was not a hidden capability. Meta's product page explicitly listed account security and recovery as a feature. What Meta did not adequately disclose was that this agent had no robust identity verification gate before executing those actions.

The attack chain — step by step

Step 1: Target selection

Attackers primarily targeted accounts that lacked multi-factor authentication (MFA) — particularly inactive or legacy accounts holding desirable usernames (short handles, celebrity/brand names, government identities). These accounts often had no SMS backup or authenticator app registered, making the AI recovery flow the only active path in.

Step 2: Geographic spoofing via VPN

Instagram's automated protection systems flag login attempts from IP addresses far removed from the account holder's usual region. Attackers bypassed this by connecting through a VPN exit node located in or near the target's home city or country. This presented an IP address geographically consistent with the legitimate owner, suppressing location-based anomaly alerts.

Attack flow:
Attacker IP (attacker's country)
→ VPN tunnel
→ Exit node IP (target's region)
→ Instagram servers
→ No geographic flag raised

Step 3: Initiating the AI support chat

With location spoofed, the attacker navigated to Instagram's account recovery flow and chose the "Chat with AI support" option. The Meta AI Support Assistant — a large language model-backed agent with write access to account settings — received the session.

Step 4: The email injection request

The attacker simply asked the chatbot to add a new email address to the target account. No proof of ownership. No secondary verification prompt. No challenge question. The bot, designed to be helpful and frictionless, processed the request.

Telegram instructions circulating at the time described the method in five words: "VPN → reset → chat → switch email."

Step 5: Verification code capture

The chatbot sent an 8-digit one-time verification code — but it sent it to the attacker's newly supplied email, not to the legitimate account owner's registered address. The attacker read the code back to the bot. The bot confirmed email ownership and surfaced a "Reset Password" button.

Step 6: Full account takeover

With the new email confirmed, the attacker set a new password. The original owner was locked out. In many cases, victims found no escalation path to a human support agent — Meta's full support layer had been replaced by the same AI that enabled the attack.

Root cause analysis

Missing: authentication before action

The core flaw is that the AI agent was given write-privileged access to account settings — specifically the ability to modify the recovery email — without a hard authentication checkpoint between intent and execution. In a correctly designed system, any request to change account recovery credentials must be verified against the existing owner's credentials, not the requesting session's claimed identity.

Confused deputy problem

This is a textbook instance of the confused deputy problem: the AI agent had ambient authority (inherited from its privileged position in Meta's infrastructure) but no mechanism to verify that the entity invoking that authority was entitled to use it. The bot was acting on behalf of whoever it was talking to — with no proof that person was the account owner.

Geolocation as the only trust signal

Meta appears to have used geographic proximity as a primary trust signal. If the requesting session's IP was near the target account's usual region, the system treated it as plausibly legitimate. A VPN trivially defeats this. Geolocation is appropriate as a supplementary risk signal, never as a primary identity gate for sensitive operations.

OTP sent to unverified address

The verification code flow was inverted. The correct design: send a challenge to the already registered email or phone number, requiring the claimant to prove access to existing credentials. Instead, the bot sent the code to the new email — the one the attacker controlled — defeating the entire purpose of the verification step.

Correct OTP flow:
User requests email change
→ OTP sent to EXISTING registered email
→ User proves access to existing credential
→ Change permitted

Flawed OTP flow (Meta, June 2026):
Attacker requests email change to [email protected]
→ OTP sent to [email protected] ← attacker controls this
→ Attacker reads OTP back to bot
→ Change permitted ← no proof of ownership of original account

No MFA bypass protection

Notably, accounts with any form of MFA enabled — even basic SMS 2FA — were reportedly protected. The exploit only succeeded on accounts with no second factor registered. This makes the design failure even clearer: the AI recovery path had no fallback requiring elevated identity proof for accounts that previously only relied on email.

Who was affected and why

The targets cluster into two groups. First, inactive legacy accounts with high-value handles — old brand pages, government accounts from previous administrations, defunct publications. These accounts often have no active owner monitoring them and no MFA configured because they were set up before 2FA was standard practice. Second, accounts belonging to individuals and organisations who had not enabled two-factor authentication.

The Obama White House account (@obamawhitehouse) falls squarely in the first category — a legacy account from a prior administration, inactive, holding a symbolically significant handle. It was defaced with an Arabic-language post claiming "The White House is under Shiites' control," accompanied by an AI-generated image of a warrior figure. Researchers attributed the campaign to pro-Iranian threat actors.

The broader context: AI replacing human reviewers

This incident did not happen in isolation. In May 2026, Meta cut approximately 8,000 employees, including staff from its integrity and cybersecurity divisions. The AI support expansion — the very system that enabled this attack — was announced at roughly the same time those human review layers were being removed. Critics have drawn a direct line: the AI agent was not supervised by the human teams that might have caught the design flaw, because those teams no longer existed in the same form.

Additionally, Meta had separately removed end-to-end encryption from Instagram direct messages in early May 2026. This compounds the takeover risk: an attacker who seizes an account can now read the victim's full message history in plaintext — something that would have been impossible if E2EE had remained in place.

Threat actor weaponisation

Within hours of the first confirmed takeovers, step-by-step exploit guides began circulating on Telegram channels frequented by hacking communities. Video walkthroughs showed the entire attack in real time. The technical barrier was effectively zero: no coding required, no specialised knowledge, just a VPN and the ability to type a request into a chat window. This is the defining risk of social-engineering-class vulnerabilities — they scale horizontally at near-zero marginal cost once documented.

Defensive recommendations

For users

• Enable two-factor authentication on every social account immediately — even a basic SMS code would have blocked this specific exploit
• Use an authenticator app (TOTP) rather than SMS where possible, as SIM-swapping remains a separate attack vector against SMS 2FA
• Add a recovery email address and ensure it is actively monitored
• Audit inactive accounts — legacy accounts you no longer actively use are high-value, low-defence targets

For platform engineers

• AI agents must not execute privileged account actions (email change, password reset, phone number update) without a hard, deterministic authentication checkpoint — not an LLM judgment call
• OTP verification must always be sent to the existing registered credential, not the new one being added
• Apply the principle of least privilege to AI agents: grant only the minimum permissions required for each support task, not broad write access to account settings
• Geolocation must never serve as a primary identity verification signal for sensitive operations
• Maintain a human escalation path — removing all human review creates a single point of failure when the AI system itself is the attack surface
• All AI agent actions on account credentials should generate an out-of-band notification to the existing registered contact before execution, with a short cancellation window

Meta's response

Meta confirmed the issue on June 1, 2026 via a statement from VP of Communications Andy Stone: "This issue has been resolved and we are securing impacted accounts." No technical detail was provided about the specific fix. Reports from Tuesday, June 2 indicated some accounts were still being compromised after the initial patch announcement, suggesting the remediation was not immediately complete.

What this incident means for AI agent security

This is one of the first large-scale, real-world examples of an AI agent being directly exploited as an attack surface — not by jailbreaking the model's outputs, but by abusing the agent's privileged actions. The LLM itself was not compromised. It behaved exactly as designed. The failure was architectural: an agent was given the power to modify identity credentials with no robust identity verification preceding that power.

As AI agents are increasingly deployed with write access to production systems — account management, financial transactions, code deployment, data modification — the security industry must develop new threat modelling frameworks specifically for agentic AI. The question is no longer only "what can the model say?" but "what can the model do, and who is authorised to make it do it?"

The Meta incident is a preview. The next one may be harder to patch.