Krebs on Security reported that attackers briefly defaced high-profile Instagram accounts after a workaround circulated on Telegram for abusing Meta’s AI support assistant during account recovery. The reported flow was not a backend database breach. It was more practical than that: attackers allegedly used the automated recovery conversation to add a new email address to a target account, receive a one-time code, and reset access.
That matters because account recovery is one of the most sensitive workflows any platform operates. It is also one of the hardest to secure cleanly. A business can have strong passwords, polished SSO, and good MFA enrollment, but if the “I lost access” path can be talked into trusting the wrong party, attackers will aim there.
What happened
According to Krebs on Security, instructions spread through Telegram channels describing how Meta’s AI support assistant could be manipulated in the password reset process. The technique reportedly involved using a VPN endpoint near the target’s normal location, initiating account recovery, and convincing the assistant to associate a new email address with the account.
Publicly visible impact included defacement of notable Instagram accounts, including accounts tied to the Obama White House and the Chief Master Sergeant of the U.S. Space Force. Meta said the issue was resolved and that impacted accounts were being secured.
Why this is bigger than Instagram
The defender lesson is not “AI support bots are bad.” The real issue is that organizations are starting to put AI or automation in front of workflows that used to require trained support staff, escalation paths, and documented proofing rules. If those automations can change recovery email addresses, reset identity factors, bypass prior MFA enrollment, or approve unusual account ownership claims, they become privileged identity systems.
For SMBs and government contractors, the same risk shows up in everyday places:
- help desk password resets for Microsoft 365 or Google Workspace,
- outsourced IT support portals,
- CRM and payroll account recovery,
- social media accounts used for brand trust, recruiting, and public communications,
- vendor portals where a recovered account can expose invoices, banking details, or contract data.
An attacker does not always need to beat your main login page. They can target the recovery process, the support desk, or the identity proofing exception path. Automation can make that attack faster if the bot is allowed to make high-impact account changes without strong guardrails.
Defensive takeaways
1. Treat account recovery as privileged access. Recovery flows should be designed like administrative actions, not customer convenience features. Changing a recovery email, disabling MFA, or issuing a reset token should require strong verification and generate high-quality alerts.
2. Require phishing-resistant MFA for high-value accounts. Passkeys and hardware security keys reduce the blast radius when a password reset path is abused. SMS is weaker, but Krebs noted that even basic MFA reportedly blocked the demonstrated exploit against accounts where it was enabled.
3. Separate “support conversation” from “security authority.” A chatbot can collect information and route cases, but it should not independently approve sensitive identity changes. Use deterministic policy checks, step-up authentication, and human review for high-risk cases.
4. Monitor recovery events, not just logins. Many teams alert on impossible travel and failed login spikes, but miss recovery email changes, MFA factor resets, backup-code generation, and support-assisted access restoration. Those events deserve the same scrutiny as suspicious authentication.
5. Inventory public-facing brand accounts. Contractors and small businesses often underestimate the value of LinkedIn, Instagram, Facebook, X, YouTube, and domain registrar accounts. Put them in the same asset register as production SaaS accounts, assign owners, require MFA, and store recovery methods in a controlled password manager.
Bulwark Black assessment
This incident is a warning shot for AI-assisted identity operations. Attackers are going to test every automated support layer for places where helpfulness outruns policy. The organizations that handle this well will not be the ones that ban every bot. They will be the ones that clearly define which actions automation is allowed to take, which actions require step-up verification, and which actions must go through a human-controlled exception process.
If a support bot can reset access to an account, it is part of the identity perimeter. Defend it that way.
