Meta Shipped Muse With a Debug Knob That Turns Any Local Process Into the Agent

A researcher on your Mac doesn't need root to hijack Meta's new AI assistant. He needs one undocumented setting. Once that setting is changed — by any process running as you, no admin prompt, no OS gatekeeper — every word you dictate to Muse, and the token that lets Muse act on your behalf, flow through his server instead of Meta's. The agent still works. Meta still thinks it's the one on the wire. And whoever is on the other end can now speak to Muse in your voice.

That is the flaw Patrick Wardle disclosed on September 22, days after Meta launched Muse at Connect. Wardle — founder of the Objective-See Foundation and a long-time macOS security researcher — named the vulnerability "not-a-mused" and put a proof-of-concept in a public repo. Meta shipped a hot-fix within a day, stripped the setting out of the client, and declined to assign a CVE.

What the setting does

Per InfoQ, Muse reads a preference key called endo_voyager_dictation_endpoint at runtime and uses whatever URL it finds there as the server for voice dictation. The key is not documented. It is not protected by macOS entitlements. Any unprivileged process running as the current user can write to it. Muse never asks for confirmation.

Per VentureBeat and Malwarebytes, an attacker points the key at their own proxy. The proxy captures the raw microphone audio and the authentication token that controls the Muse agent. It then forwards the traffic on to Meta's servers, so from Meta's side and from the user's side, Muse still works normally.

That is the whole exploit. One preference write. The attacker now has the agent.

Why that matters

Once the token is out, the attacker is not "an attacker with your mic." The attacker is Muse. Per byteiota and the Objective-See PoC writeup, that means the attacker can:

• Read what you dictated.
• Inject prompts into the agent's own input stream, as if you had spoken them.
• Reach files, camera, location, and calendar — because Muse has already been granted that access.
• Ride the linked-iPhone bridge to retrieve location data, run Bluetooth Low Energy scans, and read contacts and calendar on the paired phone.

Wardle's own summary, to iTnews, was blunt: "Please don't install. It's trivial to turn Muse into the ultimate backdoor."

The failure mode this exposes is not "attacker guessed a password" or "attacker phished a token." It is that the agent's own configuration — where it sends its traffic, and therefore who holds its identity — was itself an unprivileged, unattested local setting. Whoever gets to that setting is the agent from that moment on.

Meta's response

Per InfoQ, Meta deployed a hot-fix within roughly a day and stripped the debug preference out of production builds. David Singleton of Meta Superintelligence Labs framed the issue as a local configuration problem requiring the attacker to already run code as the user, and said a formal CVE was not warranted.

That framing is the second half of the story. The user-facing patch closes this specific setting on this specific client. But per VentureBeat, enterprise security teams still have "little central visibility into what the agent can access" once Muse is authorized against corporate credentials. Wardle also said, via Malwarebytes, that he has more Muse findings queued for Objective by the Sea in November.

There is no CVE to track. The downstream observability handle is Meta's own release notes.

The pattern this fits

Muse joins a run of 2026 findings that all say the same thing in different words: the boundary that has to hold for an AI agent is not the model's own reasoning, and not the identity that logged the agent in. It is the runtime — every actual call the agent about to make.

• On Loopjacking, the human approves operation A and the agent runs operation B, because the workflow state got mutated after the approval prompt was shown.
• On APort Vault, an out-of-model authorization check bound to the exact action drove 4,371 attacks to a 0% success rate; the same attacks succeeded 74.6% of the time against model-only defense.
• On Plugin4Shell, the approval prompt never fired because the plugin auto-updated below the prompt's field of view.
• On Muse, the token that controls the agent rides on a URL the agent reads from an unprivileged preference key.

Different products, same class of failure. Whatever the agent will do next has to be verifiable from outside the agent's own state — because that state, and the config underneath it, is what the attacker is going to bend.

The takeaway

Muse launched, made the news, and had a public zero-day against it inside the same week. Meta patched. There is no CVE. The debug knob is gone. What isn't gone is the shape of the failure: a flagship AI agent's authorization substrate lived in a local setting, and anyone running as the user could bend it.

Runtime defense for AI agents is not a research problem anymore. It is what stands between the next endo_voyager_dictation_endpoint and the mic on your desk.

Sources

• InfoQ — Un-Mused: How a Single Debug Setting Bypassed macOS Security in Meta's AI Client
• VentureBeat — Meta patched Muse's zero-day, but security teams still lack visibility into what the agent can access
• Malwarebytes — Meta's Muse AI assistant has a zero-day that can turn it into a Mac backdoor
• Unite.AI — Meta Hot-Fixes Muse Zero-Day That Let Attackers Hijack the AI Agent
• Gizmodo — Meta Just Patched a Major Zero-Day Vulnerability in Its Muse AI Assistant
• iTnews — Security researcher says don't install Meta's Muse AI assistant
• Forkast — Muse's Undocumented Endpoint Turns macOS Agent Into a Local Backdoor
• byteiota — Meta Muse Zero-Day: One Hidden Setting, Full Agent Access

SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.