I'm not sure "worked properly" and "as intended" accurately describe this situation.
But when humans handled it, this was not as much as a problem. That is, the humans did the job, because they recognized the need to do that job.
Sure sometimes accounts could get recovered if a human was tricked, but evidently it was easier to trick the LLM in masse than humans.
The problem is when the backend function doesn't verify that the email matches the username.
Meta believes that they can vibe-code their reputation down the drain by removing humans in the loop.
Applying a technical solution to a social problem almost always ends in disasters like this.
Reputation can’t be vibe-coded.
It's like, people abusing an open door. "Guys, just because we left the door open to your bedroom doesn't mean we're responsible".
God can only hope this is a business ending lawsuit.
(If anyone at Meta/Instagram sees this I wrote a brief blog post with the details. Please help! https://addisonwebb.com/blog/2026-06-05-Can%20Someone%20at%2... )
I'm creating the accounts in Meta Business Suite, so I would have a recourse with my main personal account which can be linked to some adspend, so I'm assuming it will have better support channels than accounts created through an end-user interface.
oh no...Meta what are you doing
Or perhaps said different: use the submitted info to identify the account; send any sensitive messages (recovery codes, password resets whatever) to only the contact info on file. If the chat bot can send such email it should do so via an API that sends only to contact info on file for the associated account and not to an email that's provided by the bot.
In principle, it could be designed to do so to handle cases where a new email address has been confirmed out of band, e.g. for an account representing an organization or political office. But that's a relatively unusual situation, not something you'd want to be available to every user writing in. (Even if you had an all-human support department, this sort of functionality would only be available to a select few agents.)
[1]: https://www.documentcloud.org/documents/28202858-meta-ai-ag-...
But it's important to acknowledge that there was a 'bug' in an underlying tool and not in the chatbot, and still PIP/fire those responsible for publishing the chatbot and exposed an otherwise internal tool to the public, and not those that introduced the 'bug' to an internal tool.
What I gather is that this internal tool was used by human support agents, and it was their responsibility to verify the email adresses and general validity of a claim.
But when implementing AGI TM that was overseen, maybe the oversight in the separate code path was a 'bug', but the mistake was making the chatbot obviously, if the separate code path had a bug, then it had become ossified into a feature, and it was internal, not exposed to the public.
This is an external communication, to save face sure, but if this is the internal excuse, it would be absolutely the wrong RCA and it reads as if the one who made the mistake is not admitting they made their mistake. Which to be honest, just making the mistake is enough to get fired, but not admitting it is enough to get ultra fired.
toomuchtodo•1h ago
https://www.maine.gov/agviewer/content/ag/985235c7-cb95-4be2...
sva_•1h ago
> Date Breach Discovered: 05-31-2026