You should also assume the user can read any data you send back from a tool call or data you add to a user response. If any part of the input or output is controllable by an attacker, you should be assuming some prompt injection is possible that allows them to access all data and tool calls the agent had and has access to.
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.
OTOH one could previously pay an Instagram support contractor to do an account swap, so having a human in the loop allows for other avenues of exploit:
Based on what I can tell, this bug just allows a persistent service worker to run forever by downloading a large file and not letting it complete? Security impact is pretty limited (but definitely not none).
It can make requests but only with no CORS, which could be useful for accessing some weakly secured HTTP resources behind a corporate VPN or something (in the same way any other site can but over a much longer period). It could also potentially be used for tracking user IP address activity, crypto mining, building a botnet, etc.
I assume a fair amount of these on-prem customers restrict access to their GHES instance to be behind corporate VPN or something similar and are planning a date to upgrade their instance that won't affect operations.
Any public instance should update immediately though, it's not very hard to put together how to repro the vulnerability on your own from what they provide in the article and the fact that GitHub Enterprise source is publicly available.
I suppose so. The company invested pretty heavily in security tooling, though I think it wouldn't have been hard to do something to bypass the security for internal servers.
The tweet is confusing and makes it sound like the RCE was as simple as `git push -o "x;`whatever command`"`, but there are a few more things they have to specify that they mention in their blog post: https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-38...
It doesn't look like it's very hard to reproduce or find the bug now (especially with the details they mention in their blog post) but I assume they did not want to publish the actual command line. It looks like it affected both GitHub.com and GitHub Enterprise, and it does look like it literally took one git push command.
It's interesting that Next is becoming so popular when LLMs supposedly have a capability to work with all these other frameworks that don't create a dependency on something like Vercel.
That makes sense, because JWT is base64 encoded, and those base64 tokens are bigger and more expensive. JWT has 3 parts, so it's 3x more expensive, obviously.
It has been up and down today, specifically with authentication breaking. I also saw an error message with backend SQL in it (in my 6 years of Meta bug bounty security research, I have never once seen backend SQL before).
I suspect it is because they also refactored Meta AI entirely to use Next.js instead of their normal stack they use for literally everything else. Not sure why they would do this, but I guess it works (...or maybe not) for them.
I guess this means the listener for Hey Siri requests has to be inside of the exclave/conclave to avoid triggering the mic indicator light 24/7 or leaking microphone data? I assume this means the code has to be able to be updated through various macOS/iOS updates and is not immutable, so I do wonder how the code signature verification for that works (since I assume the code signing checks would have to be done at a hardware/bootloader level above the kernel)
I also assume this means you can't put the mouse cursor over the camera indicator as well since that can be controlled by the kernel/host (if someone here has a Macbook Neo pls confirm).
What happens when you screen share - does those pixels show as active or the kernel cannot read the state of those pixels and the capture has the video memory state?
reply