Meta's Muse zero-day: one writable Mac setting hands local malware the agent's token and every linked device

Eighty-eight hours from launch to a public zero-day

Mark Zuckerberg announced Muse for Mac on X at 22:27 UTC on Thursday 17 September 2026: "It works across apps, files, calendar, notes, and messages on your computer." At 14:42 UTC on Monday 21 September, the macOS security researcher Patrick Wardle quote-posted Zuckerberg's original Muse announcement with a thread that began "Please don't install" and a public proof of concept for a zero-day in that same Mac app. The gap between the two posts is 3 days, 16 hours and 15 minutes: about 88 hours. The Muse service itself had been public for 13 days, since 8 September.

That number establishes one thing precisely: the component that failed was new, and it was not the component Meta spent its launch explaining. Meta's long security essay for Muse, published on 8 September, describes the cloud machine where the agent lives in close detail. It lists the clients that connect to that machine as "the iOS and Android apps, the web UI". The Mac app, which ships with far more local reach than any of those, did not exist when the essay was written, and the essay says nothing about it.

What the 88 hours do not establish matters as much. They do not show that anyone has been attacked: we found no report of exploitation outside Wardle's own testing. They do not show that Meta's cloud design, the Muse Secure VM we examined in yesterday's briefing on Amazon's block, was broken; Wardle himself told The Hacker News it was not. And they do not tell you whether the flaw is fixed. Wardle says Meta has pushed out what he called a "fix", in quotation marks. Meta has published no advisory, we found no CVE, and Meta did not answer Ars Technica's emailed questions and did not immediately respond to The Register.

Yesterday's question was whether a shopping agent holding a customer's password is the customer or a third party. Today's is narrower and, for a UK security team, more urgent: what happens to an operating system's permission model when the most privileged app on a device can be steered by the least privileged process on it?

What Wardle found, on the record

The primary sources are thin by design. Wardle's disclosure consists of a GitHub repository called not-a-mused (created at 14:04 UTC on 21 September, with a Python proof of concept and a short README) and a thread on X, with a follow-up post at 20:30 UTC the same day about linked iPhones. There is no long-form write-up yet; Wardle says he will present the bug, and further flaws in other AI assistants, at the Objective by the Sea conference in November. The finer detail below comes from his interviews with Ars Technica, The Register and The Hacker News, and is labelled as such. We have not linked the proof of concept and do not describe how to reproduce it.

The README describes the flaw in one sentence: Muse exposes an undocumented setting, endo_voyager_dictation_endpoint, which "a local attacker or malware can modify … without special privileges". The setting decides where the Mac app sends dictation. Ars Technica reports that Meta's developers let any locally installed app or executed code change "a long list of undocumented settings", most of them harmless, such as dark mode. This one is not harmless. Point it at an attacker's server, and the next time the user taps the microphone and speaks a prompt, the audio and text go to the attacker instead of Meta, along with the token that signs the Mac app in to the user's Muse account.

From there, Wardle showed The Hacker News three things an attacker can do: read what the user dictated; append instructions that Muse trusts and acts on; and keep the token to read the account's chat history and task the assistant directly. Ars Technica reports that his proof-of-concept attacks wrote files to disk and took photos, "in many cases with no indication to even an alert user". The README says the public code implements a subset of more than 50 commands Muse exposes.

The second post widened the reach. Because a Muse account can be signed in on several devices, the token lets the attacker send commands to Muse on any of them. Wardle used it to make the Muse app on his own iPhone report its location, run a Bluetooth scan of nearby devices and list the smart-home commands it could send. In his tests, The Hacker News reports, the assistant only drafted messages rather than sending them on its own.

What is on the record about the Muse Mac zero-day, and what is not. Sources: Wardle's repository and X posts; Ars Technica, The Register and The Hacker News, 21 to 22 September 2026; NVD search, 22 September 2026.

Question	On the record	Not on the record
The flaw	Undocumented setting any local process can change redirects dictation (README)	Affected Mac app versions
Precondition	Attacker already runs code as the logged-in user; no admin rights (README)	Whether any sandbox or signing check was meant to stop this
Remote route	One ClickFix-style pasted command is enough, Wardle told The Hacker News and Ars	Any exploitation outside Wardle's tests
Token	Sent with redirected dictation; gives chat history and direct control (Hacker News)	Token lifetime, and whether signing out revokes it
Other devices	iPhone location, Bluetooth scan, smart-home command list (X post, Hacker News)	Android clients
Cloud VM	Not shown to be broken, per Wardle (Hacker News)	Whether a token holder can clear Sentinel approvals
Fix	Wardle says Meta pushed a "fix" (Hacker News)	What it changes, which version; no advisory; no CVE in NVD
Disclosure	Full disclosure; not reported to Meta first (Hacker News)	Meta's view of that choice

Why the cloud vault did not help, and what it still protects

Yesterday's briefing turned on where Muse keeps a customer's passwords. Meta's security essay answers that in detail. Each user gets a dedicated Linux virtual machine. The agent runs in a locked-down container inside it. Credentials, including OAuth tokens for connected services and website passwords, sit in a separate service, hatch-authd, outside that container. The agent only ever handles "surrogate" tokens; the real secret is swapped in at the network boundary by Sentinel, a separate agent that Meta calls the sole permission authority for connector actions and network egress. Amazon's objection, covered yesterday, is that such a store exists at all. Nothing in Wardle's disclosure says it was opened.

That is the fair reading, and it cuts both ways. Wardle's attack does not steal a single stored password. It does not need to. It takes the steering wheel, not the keys. An agent that never sees your credentials but will use them when asked is protected only as well as the channel that does the asking, and on a Mac with Muse installed, that channel ran through a setting any process could rewrite.

Meta's essay describes the human safeguard: when Sentinel decides an action needs consent, it "sends that request directly to the Muse client", where a dialog appears outside the conversation, and the answer goes straight back to Sentinel. Two cases follow from that design. Inference, labelled as such:

• In the injection case, where the attacker appends instructions to a prompt the real user is dictating, the approval dialog should land on the real user's screen, describing an action the user did not ask for. That is a genuine chance to catch it, if the user reads the dialog rather than clicking through.
• In the token case, where the attacker drives the account directly, the essay does not say which client receives the approval, or whether a session built from a stolen token counts as one. Wardle's observation that messages were only drafted, not sent, suggests something held in his tests. Neither Meta nor Wardle has said what.

There is a second point in the essay that the Mac flaw puts in a new light. When a user signs in to a website through Muse, Meta says it presents "a custom UI on the client" to capture the username and password and route them to the credential store. The vault's guarantees start at a client. The Mac client is the part that has just been shown to trust any process on the machine. We have no evidence the credential-capture screen itself is exposed, and Wardle did not claim it; the point is that the security essay's threat model begins one step too late for a desktop app.

Access amplification: why "the Mac was already compromised" does not end the argument

The standard reply to a local bug is that once an attacker runs code on a machine, all bets are off. On macOS that has not been true for years, and Wardle's case rests on why. Apple's Transparency, Consent and Control framework (TCC) stops one app from reaching the microphone, camera, location, files or another app's data without the user's explicit consent. Ordinary commodity malware that lands through a pasted Terminal command arrives with none of those grants. Muse, to be useful, asks for most of them. Ars Technica lists writing files to disk, the microphone and camera, and location and calendars. Meta's own Mac announcement adds messages and notes, and TechCrunch's launch report adds Mail.

Wardle put it to The Register as an apartment block: a bad neighbour moving in does not get keys to every flat. An AI agent with broad grants is the building's master key hanging on a hook in the hallway. The README puts the whole story in one line: "Muse's access can potentially become the attacker's access." He told Ars: "We can manipulate the agent and leverage its privileges to do whatever we want." That is access amplification, and it is why a bug that needs a foothold is still serious: the foothold is cheap, and the amplification is the prize.

The ClickFix detail makes the foothold cheaper still. Ars Technica reports that a simple ClickFix variation, in which a web page persuades the user to paste one command into Terminal, is all that is needed. Wardle told The Hacker News there is nothing to download or install. After that, the commands that do the damage come from Muse, a signed and legitimate app. Wardle told The Register that endpoint detection on macOS has improved largely because everything is code signed, so unsigned processes stand out; an agent acting with delegated authority blurs whether a command came from the user, the agent or an attacker. Inference: a detection stack that keys on process reputation will see Muse doing Muse-like things.

Comfortable labels, and what each one covers

Every reassurance in Muse's launch is true of something. The question for a security team is what it is true of.

Friendly names around Muse and what each does and does not cover in this case. Sources: Meta launch post and security essay, 8 September 2026; Zuckerberg on X, 17 September 2026; The Hacker News, 22 September 2026.

Label	What it covers	What it does not cover here
Muse Secure VM	Isolation of each user's cloud agent and data	The Mac app on the user's own machine
Sentinel	Approval of connector actions and network egress from the VM	Who is issuing instructions to the agent
Muse has no visibility into passwords	The model never sees raw credentials	An attacker using the agent that can use them
You control what it can access	Which apps and permissions you grant	Which other processes can steer what you granted
Always asks before sensitive actions	A dialog before sending or buying	Instructions injected into your own dictated request
"Fix"	Wardle's word for a change he says Meta pushed	Any Meta description, version or advisory

None of these is a lie, and the table is not an accusation. It is a reminder that a control is defined by what it checks, and none of Muse's named controls checks the integrity of the client that talks to it. Meta's own essay is candid that "Muse isn't immune to attack" and that prompt injection "remains an open problem". The Mac flaw is not prompt injection in the usual sense. It is a conventional local configuration weakness that delivers attacker text into the agent through a trusted channel, which is arguably worse, because every classifier Meta built to spot hostile text on web pages sits on the wrong side of it.

Method and motive, on both sides

Two decisions are being argued over, and each should be judged on method, not motive.

Wardle's disclosure. Meta opened its Muse bug bounty to the public on launch day, offering up to $300,000 for valid reports and, per the essay's opening, up to $130,000 for prompt injection affecting one user. Wardle did not use it. He told The Hacker News he chose full disclosure so users would understand the risk and because it is often the fastest way to get such bugs fixed. Defenders can disagree about that. What it means in practice is that a working proof of concept was public before any fix, and that for a day at least, the only mitigation was user behaviour. Wardle runs the non-profit Objective-See Foundation and its Objective by the Sea conference, where he will present this work in November; that is the professional context, not a reason to doubt a finding that three outlets have described consistently from his own code.

Meta's architecture. Wardle's sharpest claim is that the bug exists because Meta chose cloud dictation over Apple's on-device speech recognition, and that Meta did so because it wants the data. The first half is a technical argument he makes to both Ars and The Register: had dictation stayed on the device, there would be no endpoint to redirect. The second half is his opinion, and he framed it as one. Meta has not said why it built its own dictation path. Its essay does say that conversation trajectories are used to train its models after personal data is stripped, unless the user opts out. Commercially, Meta is in a race; Zuckerberg's own Mac announcement said: "The team is shipping fast." That is context too.

The UK question: privileged consumer agents on work machines

Meta says Muse is rolling out in the US. Its download page, as we read it on 22 September, did not state any geographic restriction for the Mac app, and we could not establish whether it runs for a user signed in from the UK. The Mac version is offered as a direct download from Meta rather than, as far as we could establish, through the Mac App Store, which matters for organisations whose Mac controls lean on App Store management.

So the immediate UK exposure may be small. The pattern is not. Muse is the clearest example yet of a consumer AI agent that, to be useful, asks for Files, Mail, Messages, Calendar, the microphone and camera on whatever machine it is installed on. If a member of staff installs it on a work Mac, it becomes the most privileged app on that device, outside any contract with the organisation, with a vendor that does not publish a client threat model. The same is true of the next such agent, whichever company makes it.

Two UK frames help. The NCSC's guidance on shadow IT stresses that it "is rarely the result of malicious intent" and that organisations should meet the underlying need, keep request processes simple and take a no-blame approach, so that staff report what they have installed rather than hide it. That is the right tone for asking who has already put an agent on a work machine.

The second is data protection. Under Article 28 of the UK GDPR, a controller may use only processors that provide sufficient guarantees, under a binding contract. Inference, not legal advice: a staff member's personal Muse account, dictating work content to a consumer service whose published policy uses sanitised conversations for model training unless the user opts out, is not that arrangement. Wardle's bug adds a security dimension to a compliance problem that already existed.

What to do, in order

# Read-only checks for a managed Mac. Run as each local user.
# 1. Search every preferences domain for the key Wardle named
defaults find endo_voyager_dictation_endpoint

# 2. Look for an installed Muse application bundle
mdfind "kMDItemKind == 'Application' && kMDItemDisplayName == 'Muse*'"

The question that exposes the gap

Meta built a careful answer to the question of what happens when the agent is tricked by what it reads. It built a vault so the agent never sees a password, and a Sentinel so nothing leaves the machine without a check. What Wardle's 88-hour zero-day shows is that the question that matters on a desktop comes one step earlier: when an instruction reaches Muse, how does anything in Meta's system know it came from the user?

Ask the narrow version of that of any agent vendor before it lands on a work machine. When someone holding a stolen session token tells the agent to act, whose screen does the approval appear on?

Key facts