Muse 0-Day Lets Any App Hijack Meta AI Agent
A Muse 0-day found by Patrick Wardle lets any local app or terminal command seize the Meta AI assistant's authentication token.
Muse 0-day has turned Meta's newly launched AI assistant into a launchpad for attackers. That's the claim. And the security researcher who found it says the company's own design choices opened the door, which means the flaw didn't come out of nowhere but instead grew from decisions Meta made itself. A zero-day vulnerability gives any locally installed app or terminal command complete control of the agent. So says Patrick Wardle, the macOS security expert who discovered the flaw.
Meta introduced Muse a few weeks ago. It's a productivity powerhouse, they say. The assistant books appointments, fills out forms, handles customer service, makes purchases, generates images, creates documents, and connects with other apps and services, which means it's doing a lot of work you'd normally do yourself across a dozen different tools. It also taps into a user's WhatsApp, email, calendar, and social media accounts. There's a macOS app. And curiously, no Windows version.
How the Muse 0-day Actually Works
The trouble starts with the permissions Muse demands to function. Users must authenticate the assistant with every service it touches. Because the app runs on macOS, it also needs broad access to operating system resources: writing files to disk, using the microphone and camera, and monitoring location and calendars.
Apple spent years building defenses to stop installed apps and terminal commands from reaching those resources. Muse rolls right past them. The Muse 0-day lets any app or executed code access the token that authenticates a user to their Muse account, regardless of what macOS permissions that code holds.
Wardle traced part of the problem to a long list of undocumented settings that any local process can change. Most are harmless. Dark mode, for instance. One setting is not. It controls the endpoint where transcription happens.
From Dark Mode to Total Takeover
Normally, transcription runs through a server address operated by Meta. Attackers can redirect that traffic. But they don't send it to Meta. They send it to an endpoint they control, and once that switch happens, the authentication token follows right along with it, which means the attacker now holds complete control over the Muse account.
"We can manipulate the agent and use its privileges to do whatever we want," Wardle told Ars. "So instead of us having to write a very thorough Mac malware stealer, we can just use the AI assistant itself."
Wardle built several proof-of-concept attacks. They write malicious files to disk. And they snap pictures. In many cases, even an alert user, the kind of person who watches every process and checks every log, gets no indication that anything happened, because these attacks don't leave the usual traces you'd expect. It's silent.
There is more than one route in. An attacker's server can sit as a proxy between the Muse user and the Meta endpoint. When the user speaks a prompt, the malicious server appends a command, such as shipping an archive of all WhatsApp messages back to the attacker. The token travels to the malicious server too, which means permanent control.
A Single ClickFix Is All It Takes
The entry point is uncomfortably simple. A variation of a ClickFix attack, the social engineering technique that has proven very effective at tricking people into infecting their own devices, is enough to seize a Muse account.

Developers of exploitable apps often argue that once a device is compromised, all bets are off. That defense doesn't fit here. The bar should be far higher. And they're the ones who built an assistant holding this much access, so we've got to ask why that bar isn't higher already.
To me, the bar is infinitely higher in terms of the security of these apps, Wardle said. They don't have to be perfect. But when you take a look at Muse, it's like they didn't, in my opinion, think about security, which is really worrisome.
Meta's Design Decisions Under Scrutiny
Wardle pointed to specific choices. Muse handles dictation in the cloud, where Meta can log it, and that's a fact. MacOS has offered a simple way for apps to handle dictation and transcription on-device for years, a safer path that was right there for the taking. Had Meta chosen that path, the attack would not have worked. So it didn't.
The second decision is broader. Any app can control all the undocumented settings. Meta likely intended partner apps to adjust interface preferences, which is reasonable. But letting any process redirect the endpoint where sensitive user speech gets processed, the place where that data is handled and routed, is an entirely different matter, and it's one they can't wave away.
- Cloud dictation instead of on-device transcription
- Undocumented settings controllable by any local app or command
- An endpoint switch that leaks the account authentication token
Meta representatives did not answer emailed questions. The company has published two posts in as many weeks documenting the design decisions meant to keep an assistant with extraordinary access secure and private. Those posts land amid revelations that internal testing of models from Anthropic and Google caused security breaches of external third-party networks the engineers never intended to target. In human-only hacking, such actions could invite criminal charges. The posts read as an effort to head off blowback and calls to slow AI development.
Amazon Blocks Muse Before the Disclosure
Amazon started blocking people from using Muse to shop on its site. That's a fact. It happened roughly 12 hours before Wardle disclosed the Muse 0-day, a timing that matters because users who tried to shop got a message calling Muse an "unauthorized AI agent [that] violates Amazon's Conditions of Use." And they're not wrong.
Amazon framed the move as standard practice. "We think it's fairly straightforward that third-party applications that offer to make purchases on behalf of customers from other businesses should operate openly and respect service provider decisions about whether or not to participate," the company said in an emailed statement. Amazon compared agentic apps to food delivery services, package delivery apps, and online travel agencies, and said it requested that Meta remove Amazon from the Muse experience.
Amazon's block landed hours before anyone outside a small circle knew about the vulnerability, which means the two events are separate headaches arriving on the same doorstep.
What Comes Next
For now, Muse users have little to go on. Meta hasn't answered questions about the flaw. And there's no word on a fix. Anyone running the assistant should treat the account access it holds with real caution, particularly the WhatsApp, email, and calendar connections an attacker could quietly drain, because that access is exactly what makes this flaw so dangerous.
Wardle plans to detail the vulnerability at the Objective by the Sea security conference in November. He runs the Objective-See Foundation. It's a nonprofit focused on macOS security. And he wrote "The Art of Mac Malware" book series, previously worked at NASA and the National Security Agency, and now plans to lay out the vulnerability and other AI assistant threats at that November conference. He can't ignore what's coming.
His verdict is blunt. He doesn't dress it up. Like most AI agents, and contrary to Meta's claims, Muse cannot be trusted, and whether it ever can be is an open question that nobody, not Meta, not the researchers, and not the assistant itself, has managed to answer. So don't trust it.
- Muse asks for deep access to accounts and device resources
- Apple's protections exist precisely to stop this kind of reach
- Wardle's proof-of-concept attacks ran without alerting the user
Frequently Asked Questions
What exactly does the Muse 0-day vulnerability allow any locally installed app or terminal command to do?
The Muse 0-day lets any app or executed code access the token that authenticates a user to their Muse account, regardless of what macOS permissions that code holds. This gives such code complete control of the agent, enabling it to manipulate the agent and use its privileges to do whatever the attacker wants.
Why does the Muse 0-day exist, according to the researcher who discovered it?
Wardle traced part of the problem to a long list of undocumented settings that any local process can change, including one that controls the endpoint where transcription happens. He also pointed to Meta's decision to handle dictation in the cloud instead of using macOS's on-device transcription option, saying that had Meta chosen the on-device path, the attack would not have worked.
How does an attacker turn the transcription endpoint setting into full control of a Muse account?
Normally transcription runs through a server address operated by Meta, but attackers can redirect that traffic to an endpoint they control. Once that switch happens, the authentication token follows right along with it, which means the attacker now holds complete control over the Muse account.
How does an attacker get in to begin with, and what might the victim experience?
The entry point is a variation of a ClickFix attack, the social engineering technique that has proven very effective at tricking people into infecting their own devices, and it is enough to seize a Muse account. In many cases, even an alert user who watches every process and checks every log gets no indication that anything happened, because these attacks are silent and don't leave the usual traces.
What did Amazon do about Muse, and when did it happen relative to the disclosure?
Amazon started blocking people from using Muse to shop on its site roughly 12 hours before Wardle disclosed the Muse 0-day. Users who tried to shop got a message calling Muse an unauthorized AI agent that violates Amazon's Conditions of Use, and Amazon said it requested that Meta remove Amazon from the Muse experience.
๐ฌ Comments (0)
No comments yet. Be the first!













