I wonder how Claude Fable will live up to expectations and how good those Fable/Mythos classifiers really are. It seems a bit convenient for Anthropic to release this magical insane model when they are about to IPO.
They do this by allowing you to download all of the components (minus data cryptexes containing the model weights) and run it on your own Apple silicon chip (you can put your computer in recovery mode and use csrutil to enable research guest operating systems)
I think what is concerning is that they are expanding into Google Cloud and NVIDIA to run with it too with their versions of confidential compute, which if I remember correctly are not as well verified as Apple PCC and a little harder for researchers to get their hands on.
Apple uses a key ceremony process where no single party has access to all the keys required to sign hardware, meaning in theory they can’t just sign malicious hardware. However, I’m not sure how Google and NVIDIA play into this and I don’t think they’ve provided much detail on it. I think it seems a little rushed to get the features out since they fucked up with initial Apple Intelligence release.
From my understanding of the architecture, Apple and Google have basically developed a fork of Gemini that is built to run on Apple's PCC. There is no data being sent to any Google servers.
From this MacRumors article:
"The new architecture centers on Apple Foundation Models co-developed with Google, which Apple says are adapted to run both on-device and on servers through its existing Private Cloud Compute infrastructure."
And
"The company reiterated that Apple Intelligence relies on on-device processing and Private Cloud Compute, with a promise that user data is only used to execute the immediate request and is not accessible to Apple or third parties. Apple added that outside experts can verify those privacy guarantees "at any time.""
That seems to conflict with the recent security blog that says they are using Google Cloud infra and NVIDIA GPUs with PCC now [0].
They are allowing it to run on Intel and NVIDIA and Google chips meeting certain requirements now too instead of just Apple silicon because they think they’re secure enough now, but I suspect this decision might have been pushed by the need for Siri to be useful.
I still definitely think it’s better than what every other company is trying to do (like running a variant of OpenClaw 24/7 forwarding data to Anthropic, OpenAI, Google, and every other provider they can support).
It's not the compute hardware itself. PCC used to be data centers owned and operated by Apple, running on chips designed by Apple.
With this announcement, Apple is expanding the definition of PCC to Google Cloud data centers. Theoretically, this is Google Cloud, not Google servers, so there should be a separation of access there.
From the Apple security blog:
> Originally built exclusively on Apple silicon with our world-class software security technologies, PCC set a new bar for AI privacy in the cloud, and continues to power the most demanding Apple Intelligence features. Since then, the wider industry has been working to provide a set of confidential inference primitives that could theoretically be combined to reach the security level of PCC. However, until today, those primitives have never been integrated into a comprehensive, end-to-end confidential inference pipeline capable of operating at global scale. That’s what we’ve done with PCC on Google Cloud, which incorporates PCC’s exceptional security and privacy properties at every stage, including the industry’s most comprehensive transparency guarantees that allow external security researchers to verify our privacy commitments.
I think it's because Apple would have to provide every competitor (including ones running off-device with no confidential compute) with the same level of access Siri AI would get, which poses a lot of security and privacy concerns Apple would never allow third-party developers to get access to even with a TCC consent prompt (like reading and sending iMessages).
No, it's more that those apps needs to be able to make all of the tool calls Siri AI can make, which would allow third-party developers to collect data they shouldn't have access to.
App developers can already access the on-device foundational models through an API, but I don't think many developers want to do that because there are better models.
Not exactly, I think part of the tools it has access to allows it to perform an "investigation" into recent malicious activity and account changes that may have occurred that were likely unauthorized (such as changing from an email used for a long period of time to a new one). I think this AI-version of this check was originally broken and just allowed any email but has now been fixed to only be emails that look like they were attached to the account, which is what the poster used to obtain access back into their account.
The bug still exists - two of my friends have lost access to their accounts as of an hour ago. They've partially recovered but are unable to change their passwords, so their accounts are still technically in the hands of the attacker(s).
Yeah, it seems another ATO bug has popped up. I haven’t looked too much at it personally, but I hope Meta plans on taking their Meta AI Support Assistant offline until it undergoes far more rigorous security review.
It seems pretty trivial to just add a check in the agent's tool call to determine if the email is actually the one on file (or one that has previously been on file). I'm not sure why it's taking them so long to remediate.
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.
reply