Meta Muse flaw widens local attack surface

When Meta introduced its Muse AI assistant earlier this month, the company put security front and center, pointing to an architecture it calls Muse Secure VM and promising that each user retains control over how much access the assistant receives. A proof-of-concept released by a veteran macOS security researcher suggests that promise may be narrower in practice than in marketing — at least when malicious code is already running on the same machine.

The issue is not a remote attack. It does not let someone on the other side of the internet reach into a Muse installation. What it does is give code that has already landed on a Mac a path to reach further than it otherwise could, by rerouting the assistant's dictation pipeline to a destination of the attacker's choosing.

A setting nobody documented

Patrick Wardle, founder of the nonprofit Objective-See, published a proof-of-concept he calls not-a-mused, describing it as a local zero-day in the Muse macOS app. His writeup centers on an undocumented configuration value named endo_voyager_dictation_endpoint. According to Wardle, an attacker who can run code locally can modify that setting without any special privileges.

The practical effect is that Muse's dictation traffic can be pointed at an endpoint controlled by the attacker rather than Meta's backend. That traffic can include dictated audio and the prompts being sent to the backend AI model, which means the exposure extends beyond raw voice data into whatever instructions the user is relaying to the assistant.

Wardle describes several follow-on risks: prompt injection, theft of authentication material, and abuse of whatever permissions the user has already granted to Muse. Because the flaw sits in how the app handles a locally writable setting, it functions as a privilege escalation path — local malware that would otherwise be boxed in can ride the assistant's own access.

Why local-only still matters

The remote-attacker caveat is real, and Wardle does not overstate it. Someone needs the ability to execute code on the target machine before any of this applies. But that precondition is common enough — commodity malware, a malicious installer, a compromised dependency — that the distinction between "local" and "harmless" is thin.

"Just because a bad neighbor moves in doesn't mean that that neighbor automatically has access to all the apartments."

— Patrick Wardle, founder of the nonprofit Objective-See

The apartment-building analogy captures his core complaint. Operating systems have spent years building walls between processes, and an AI assistant that has been granted broad access to files, tools, and services can end up handing a tenant a master key. Wardle's framing is that the vulnerability matters chiefly because it converts a limited local foothold into something considerably broader.

Apple's guardrails, and where AI apps sit

Wardle credits Apple with doing strong work on the Transparency, Consent, and Control framework, the macOS mechanism that governs access to sensitive data, and on privilege separation more generally. His concern is that AI applications can undercut those barriers because they ask for — or require — so much access to data and tools to be useful.

"They're super convenient and super empowering. But they have so much access if you configure them to be useful. They basically could do anything on your computer."

— Patrick Wardle, founder of the nonprofit Objective-See

That combination makes an AI assistant a potential single point of failure for the security controls underneath it. The same permissions that let Muse read, write, and act on a user's behalf are the permissions an attacker inherits once the assistant's traffic can be steered.

The detection problem gets harder

Endpoint detection and response tooling on macOS has improved considerably, Wardle notes, in large part because code signing is pervasive: unsigned or un-notarized processes stand out and can be blocked. AI agents scramble that picture. When an agent holds broad permissions, an EDR product struggles to distinguish a command that came from the user, from the agent acting on the user's behalf, or from an attacker who has subverted the agent's channel.

That ambiguity is not a flaw in any single EDR product so much as a consequence of how much trust these assistants are given. The tools were built to spot bad processes. They are less equipped to adjudicate intent inside a process that is supposed to be doing privileged work.

An API Meta chose not to use

Wardle points out that Apple offers on-device local dictation, and says that if Meta had used that API, this particular vulnerability would not exist. His read is that Meta opted against Apple's service because it wants access to the dictation data itself.

"I think some of their greediness for user data kind of opens the door, makes a bigger attack surface. But at the end of the day, these AI companies, they're racing for what's next. User privacy and security, those aren't priorities."

— Patrick Wardle, founder of the nonprofit Objective-See

He also questions whether the companies building these assistants are turning their own bug-hunting capabilities inward. "You know these AI companies have really great AI models for finding bugs," he said. "Are they not running them against [their own apps]? Is the priority not the security of their own apps?"

What the researcher wants to see

Wardle is not arguing that assistants should be stripped of access. He acknowledges that agents need permissions to be useful at all. What he says is missing from the companies building them is a sense of responsibility for how much access their apps seek in the first place.

That gap is what turns a locally writable preference into a security problem. A setting that redirects dictation traffic is, on its own, an implementation detail. Combined with an assistant that has been granted wide latitude over a user's machine, it becomes a lever.

• An undocumented setting, endo_voyager_dictation_endpoint, can be modified by an unprivileged local process
• The flaw requires the ability to run local code; it is not remotely exploitable
• Potential consequences include prompt injection, theft of authentication material, and abuse of granted Muse access
• Meta's launch messaging referenced Muse Secure VM and user control over access
• Meta did not immediately respond to a request for comment

What users and admins can take from it

For anyone running Muse on a Mac, the immediate takeaway is that the app's security posture depends heavily on what else is running on that machine. Local code execution is the entry condition, so the usual hygiene around installers, downloaded binaries, and untrusted developer tooling applies with more force when a broadly permissioned assistant is present.

It is also worth being deliberate about how much access an assistant is granted. Wardle's argument is that convenience scales with permissions, and so does the blast radius when something goes wrong. Users who can keep an AI app's reach narrower without losing the features they actually use are reducing the surface an attacker could inherit.

For security teams, the harder question is detection. If an agent's commands are indistinguishable from a user's, and the agent itself can be rerouted, then endpoint tooling built around process identity has less to work with. That is a structural issue rather than a patchable bug, and it applies to any assistant granted comparable reach.

Why it matters

The Muse case is a reminder that privilege escalation does not always arrive through a kernel bug or a sandbox escape. Sometimes it arrives through a configuration value that an assistant treats as trusted because the assistant was built to be trusted. As more of these apps ask for broad access to files, tools, and services, the operating system's careful separation of powers matters less if the app sitting on top of it can be steered.

For Meta, the open question is how it responds — whether the setting is locked down, whether the app moves to platform-provided dictation, or whether the company disputes Wardle's characterization. Meta did not immediately respond to a request for comment, so the picture of what the company intends to do remains incomplete.

For everyone else, the pattern is the one to watch. An assistant that can read your messages, see your screen, and act on your behalf is a high-value target, and the security of the whole arrangement rests on how carefully its access is bounded — including the parts of it that nobody documented.