Comment by hbn
3 hours ago
It's insane the AI has been provided the tooling to send emails to arbitrary addresses like that. Like, getting it to send a 2FA code at a user's request is one thing. But it should only be able to "hit a button" to send a 2FA email to the address attached to the account, all run with hand-written code. It shouldn't have access to the 2FA code itself, or the message subject, or body, or the recipient address, etc.
Why did they give it any of that?!
This exploit has essentially nothing to do with AI and everything to do with a terribly designed account recovery flow.
This exact same flow could have been (and may have been; I don’t know how much the chatbot here actually does) statically coded.
The AI part does seem relevant because it enabled incredibly low-effort “social” engineering.
For what it’s worth I don’t think you can call this social engineering since there was no human on the other end, even though it appears similar.
The question is, if there were actual human support agents, would they have built additional safeguards to prevent social engineering in this manner?
a human would have noticed something different about the requests it was getting, or the frequency of requests, and as soon as it noticed a shift, it would have carried that knowledge forward and intensified the scrutiny if something seemed off- eventually communicating it up the chain.
- instead of the ai context dying.
in the ai case, information only survives to the extent where the ai is empowered to store a note or notify a manager of an observation. Anything that does not result in sending a message/storage is wiped
Why did the account recovery system need AI. Surely just an email would do? What added value would AI add?
1 reply →
There's no social engineering here, since all they have to do is copy and paste. This is a complete process design fail.
My impression is that AI didn't replace static code in this place; it replaced a person, who (hopefully) would have been suspicious about sending an account recovery code for e.g. "obamawhitehouse" to e.g. "bscurtu.alfamm.ro@gmail.com"
You're giving a lot of credit to the human alternative, especially considering that the attacker only needs to find one lazy human.
3 replies →
This is not true. Well, it kinda is, but nobody will be stupid enough to hand-code an account recovery where you get to type any email address.
The reason it worked there is that the designers of the system didn't anticipate that the AI will agree to accept any email (maybe they even put guardrails against it in the system prompt, we don't know). It's more like social engineering than bad-security-code, except that like the sibling comment said an actual human will probably not approve that.
> The reason it worked there is that the designers of the system didn't anticipate that the AI will agree to accept any email (maybe they even put guardrails against it in the system prompt, we don't know).
These are contradictory cases. If you put guardrails into the system prompt, you've anticipated that the AI will take the action you're guardrailing against. And since AI prompt compliance is at best stochastic (and realistically just crap, over large sample sizes), every guardrail is an explicit recognition of a failure -- the guardrail will be ignored, and you can't pretend you didn't realize it was a problem, since you put it in.
1 reply →
Maybe? I don’t know what logic was actually in the LLM vs it just using a bad tool. Unless I missed it, the article had no actual context on that either.
This looks like a terrible design rather than an AI problem to me, though.
5 replies →
> This exact same flow could have been…statically coded.
But had never been until it was wrapped in a chatbot. It’s just about unheard of for a major site in the modern era, isn’t it? I think the AI factor is essentially essential. All but.
The reason all these meticulously designed flows have been done away with is because some manager believes that AI is omniscient and can just replace it all.
Like, flagging VPN endpoints is bread and butter for this kind of thing and must already exist. But it's been bypassed
Residential proxies won’t get flagged and are easy to obtain, if expensive.
I agree with your point, mostly.
Until I remember seeing someone saying "MCP is dead, we just give agents command line access now". Then I start to think that looking at this in the context of ai is helpful.
An email address is making its way from a publicly available LLM prompt input to a sensitive email's recipient address. That's the problem I'm highlighting.
Drowning has essentially nothing to do with water and everything to do with a terribly designed ability to get air into your lungs.
If you'd do a retrospective and ignore how AI has shaped expectations and a company's culture to allow this to pass through into production, you'd be complicit/perpetuating what led to this debacle in the first place.
It's not the end of the world, and water isn't going anywhere, but saying AI has essentially nothing to do with it is just a bad take.
This sounds like it was “designed” by an actual idiot. Maybe vibe coded on a Saturday.
Nobody would handcraft a password reset flow that ignores the users' email and 2fa settings lol
Also I've used Meta's old password recovery system. It's not possible to do this in that version. The chatbot is what makes this possible.
Vibe coded?
I do a lot of bug bounty research on Meta and Instagram, and some of the bugs I find look extremely simple like this but have some slightly complicated reason for why they occur. Maybe not this one, but I do have a guess as to what might have actually happened.
Based on what I've seen so far, Meta AI Support Assistant (they call it "MAISA") had tool calls that a) start an email verification to any specific email, phone number, or the contact points linked to an account and b) allow generating a password reset link for an account based on an email verification attempt. I don't think it had any access to the actual codes themselves, but rather think a handle or ID for an email verification attempt (along with the user provided verification code based on user input) was provided to the "generate reset password link" tool call, and the tool call failed to properly validate the actual email used in that attempt belonged to the account allowing the ATO.
The tool call for MAISA to generate a password reset link should have failed with an email verification attempt that corresponds to an email not linked to the account (and I believe I even tested this at one point on Facebook and encountered an error that successfully prevented it), but I suspect they tried making a change to this tool call for Instagram where slightly older, recently unlinked emails could be used to recover an account that got hijacked by an attacker, which added the need to allow emails not currently linked to the account to be used and set to the user's primary email.
I also suspect that the MAISA tool call change called a wrong API or something that unintentionally allowed any email verification attempt that was successful to be used, but the engineers did not add a sufficiently thorough e2e test case to test the tool call against unrelated email verification attempts being provided to the tool call. This is the part I think should be focused on the most. Tool calls for agents that have their output potentially influenced by an attacker should be treated like external APIs that anyone can reach, and they should be tested as such.
This is all obviously a guess, doesn't take into account the many signals they use to determine if an account recovery attempt is valid, and could be very inaccurate, but it's the closest to what I (someone who deals with Meta security a lot) think could have allowed this to happen.
> but the engineers did not add a sufficiently thorough e2e test case to test the tool call against unrelated email verification attempts being provided to the tool call.
I'd go out on a limb to say the tests were likely AI generated. It's easy to miss a case like this one given that models like to generate a ton of test code that 'look' good at a glance but have subtle logic bugs that could potentially defeat the purpose of the test itself.
My own anecdata here, Claude generated a JUnit test with all the right setup, but missed a crucial assertion (there were very many other minor assertions) which made the test useless mostly.
Seems like the most plausible explanation. OTOH it feels like this is the sort of thing that might have been discovered/mitigated more quickly had there been a human in the loop.
This reeks of vibe coding. "Make it so the AI agent can help with password resets" and then zero human vetting of the change.
The human vetting was that it was cheaper. Someone probably got promoted for it.
And zero accountability too. No one will be found and detected.
Yeah it's bad, but AI isn't required for this type of thing to work.
My anecdotal experience is my Facebook account was compromised several years ago after TOTP 2FA was disabled. Didn't exactly give me a warm fuzzy about Facebook security policies at the time, and this new attack just reaffirms that.
Some Jr engineer got tired of handling stupid support requests and automated the job with an agent. That’s how.
Assigning Jr engineers for security support is ridiculous partly because young people don’t understand how critical security is sometimes. And partly because they don’t value privacy as much.
As a "young person" (under 30), my thoughts: There's a minority of us that do genuinely care, possibly more than most - so hiring someone from this minority would be helpful - but the vast majority of my peers don't care about privacy nor security. They often take this defeatist mindset of "my data is already out there, why should I care?", or prefer convenience over security. For example, "why should I switch to Signal if I have a public Instagram profile?" or "I can't remember all those passwords! I just use one for everything."
As for your comment about junior engineers, see kennywinker's reply to this thread - I share the same thoughts.
If a single junior engineer can do this, it’s an even bigger indictment of Facebook’s senior management than this exploit. A well-designed system doesn’t rely on individuals never making mistakes and if our hypothetical junior developer can make critical security policy changes without oversight, that should be a C-level job loss event.
If our goal isn’t to make excuses for the top of the org chart, a more likely explanation is that senior management is heavily incentivizing shipping AI features and this went out as a high-impact change reviewed in a rush, probably by AI.
Very generous of you to blame the screw up of one of the largest companies in the world on a jr engineer.
I’ve been a jr engineer at a large company. I had the power to implement absolutely jack shit on my own. I deeply doubt the security flow for account recovery in meta ai account security was a single jr engineer.
What i think is actually going on is basically a soft form of ai psychosis. Senior engineer gets ai to code ai account recovery feature, that same or a different engineer asks ai to review the feature, and then it gets pushed to prod. Move fast, break things. The ai coded it, the ai reviewed it - the people trusted the ai because it sounds confidently right.
Just like how the ai doesn’t know if you should walk or drive to the car wash, the ai doesn’t understand exploits like this one.
...yeah, but its CEO is also who he is. The guy who refers to people using his products as "dumb fucks". That's kind of important
> But it should only be able to "hit a button" to send a 2FA email to the address attached to the account, all run with hand-written code.
Genuine question...why would that need to be hand-written?
It makes absolute sense as a general statement and is kinda crazy that this wasn't a built-in limitation, but I'm not quite sure why the code for that bit must be hand-written (provided the code functionally does what you describe).
I think he likely means "code that is hand-reviewed" and not directly controlled by the agent. He's probably meaning to differentiate it against the in-process agent writing the code. It doesn't matter too much if that fixed code was written by an LLM under guidance and review of the SWE, outside the agent.
Ahh ok - that's fair enough - hand-reviewed/not controlled by the agent seems a sensible approach (wasn't sure if it was instructive of a complete distrust of AI generated code)
Agreed, “literally written by hand” didn’t cross my mind. Not by keyboard or pen.
Maybe not hand-written, but definitely static, and at least human-reviewed/tested to only allow sending to previously-validated email addresses.
Right, as in, does not accept an email as a parameter. If its anything like my company they are turning out "agents" super fast and just hooking them up to internal APIs usually via a light MCP wrapper. Since MCP doesn't have any security or auth built in, and internal APIs usually are light on security you have issues like this.
One would have to assume that this was by design.
It's stuff like this that honestly makes it very hard for me to take anyone working at Meta seriously. How much communication had to happen to enable this feature? It really casts doubt across the organization at multiple levels, don't tell me a single engineer caused this.
I can't take Meta seriously, period.
The harness is vibe-coded.
This exploit is my new gold standard for trivially avoidable security failures. Someone has finally beaten Gitlab's password reset emails to attacker-provided addresses.