Meta’s new Muse agent for Mac has acquired a serious security problem less than a week after its release. Mac security researcher Patrick Wardle has published a proof of concept called Not a Mused, showing that an unprivileged local process can redirect Muse’s dictation traffic to a server controlled by an attacker.
The attack can expose dictated prompts and authentication material, while giving the malicious server an opportunity to inject its own instructions. Because Muse can operate across files, websites, and macOS applications, those instructions could make the agent misuse whatever access its owner previously approved.
This is not a remote, zero-click compromise of an otherwise clean Mac. The attacker must already have a process running under the victim’s account. The flaw is dangerous because that process needs no administrator or root privileges, yet it can potentially turn Muse into a bridge to more sensitive data and capabilities.
The Muse Zero-Day Turns a Local Foothold Into Agent Control
The vulnerability centers on an undocumented Muse preference called dictationUrl. Wardle’s research shows that an ordinary local process can use the built-in macOS defaults utility to change this preference under Muse’s application domain, com.meta.muse.
Once altered, the setting tells Muse to send dictated commands somewhere other than Meta’s intended service. The destination can be any URL chosen by the attacker. The request reportedly includes both the words dictated by the user and authentication information associated with Muse.
The attack has a relatively short chain:
- Malware or another untrusted process gains execution under the current macOS user.
- That process changes Muse’s hidden
dictationUrlpreference. - The user dictates a prompt to Muse.
- Muse sends the prompt and attached authentication material to the attacker’s server.
- The server can record the prompt, alter the interaction, or return instructions designed to control the agent.
- Muse may carry out those instructions using permissions the user previously granted.
Changing the setting requires no password prompt, administrator approval, or macOS privilege escalation. The attack targets Muse’s own configuration and trust model.
The zero-day does not automatically install malware or provide the initial foothold. It makes an existing foothold much more valuable by placing a powerful AI agent under the attacker’s influence. In security terms, Muse can become a confused deputy: trusted by the user and the operating system, but directed by an untrusted party.
Wardle said he shared the issue with Meta before publishing the repository. As of September 21, 2026, the public disclosure does not identify a patched Muse version, and the company’s Muse Security page contains general reporting instructions rather than an advisory for this flaw.
The Real Risk Is Muse’s Access, Not Just Its Prompts
Prompt capture alone can expose sensitive information. People may dictate private messages, summarize internal documents, discuss financial records, or provide instructions involving work accounts. Authentication material is potentially more serious because it may enable abuse beyond a single intercepted conversation, although the public disclosure does not fully document its form or whether it is reusable.
The larger concern comes from Muse’s role as an agent. Meta presents Muse as a macOS assistant capable of working across applications, websites, and local content. That broader reach makes the product useful and increases the effect of a successful hijack.
Depending on the permissions approved by the user, a compromised Muse session could potentially interact with:
- Local files and folders
- Apple Mail
- Messages
- Calendar
- Notes
- Browser sessions and websites
- Other supported macOS applications
The attacker does not instantly receive unrestricted access to every item on the Mac. Reachable data and actions remain tied to what Muse can access and what the user has permitted. Even with that limitation, there is substantial room for abuse if Muse has been configured as an everyday assistant.
Apple’s macOS privacy controls normally require consent before applications can access protected information such as calendars, contacts, photos, microphone input, and certain files. Users can later review those permissions under Privacy & Security. The Muse attack can misuse an already trusted application without requiring the attacker’s process to obtain every permission independently.
A malicious process that cannot directly read Mail or Calendar data may be able to inject instructions into an agent that can. Muse’s permissions then become an indirect path around the restrictions facing the original malware.
A Former Meta Security Manager Says He Would Not Use Muse

An International Cyber Digest post says a Meta AI security engineering manager who left the company in September 2026 responded to the disclosure by saying he would never use Muse because of its security and privacy implications.
2102108849893158963The warning is notable, particularly because it comes from someone described as having managed AI security engineering inside Meta. It should still be separated from the technical evidence. Wardle’s repository demonstrates the configuration problem, while the former manager’s refusal is a personal risk judgment. The cited material does not establish whether he reviewed Muse directly or worked on the product’s security architecture.
His reaction points to a broader trust problem. Desktop agents require users to accept an unusually concentrated security relationship. One application may see messages, documents, schedules, browser activity, and spoken instructions. A flaw affecting the agent’s control channel can have consequences that would normally require several separate application compromises.
The published proof of concept gives the concern a specific basis: an attacker-controlled endpoint can be inserted into Muse’s dictation flow without elevated privileges.
Meta’s Privacy Claims Do Not Eliminate Endpoint Risk
Meta says Muse uses local processing for sensitive information and that prompts are not used to train its AI models by default. Those measures address legitimate privacy concerns, including unnecessary cloud retention and model training on personal data.
They do not address the vulnerability Wardle disclosed.
Local processing protects data only while the local application and its control paths remain trustworthy. If malware can redirect part of the application’s traffic, the distinction between local and cloud processing becomes less meaningful. The attacker does not need Meta to collect a prompt when Muse can be instructed to send it directly to an attacker-controlled service.
The same problem applies to credential storage. Protecting authentication tokens on disk is insufficient if the trusted application can be manipulated into transmitting authentication material to an arbitrary endpoint. Security must cover where credentials are stored, which components can use them, and which destinations may receive them.
A complete fix should do more than hide or rename dictationUrl. Meta needs to remove arbitrary production endpoint overrides or strictly validate them. Muse should also avoid attaching reusable authentication material to any destination that has not been authenticated as a Meta service.
Other useful safeguards would include:
- Cryptographic verification of service endpoints
- Alerts when sensitive configuration values change
- Separate, narrowly scoped credentials for individual Muse functions
- Explicit confirmation before accessing or sending sensitive data
- Clear logs showing which prompts and actions Muse executed
- Easy permission revocation for individual applications and data types
These controls will not make an agent immune to prompt injection, but they can prevent one altered preference from turning a local process into an agent operator.
What Muse Users Should Do Before Meta Ships a Fix
Anyone using Muse on a Mac should treat the disclosure as an unpatched local security risk until Meta identifies a corrected version.
For security-sensitive users, the safest option is to stop running Muse temporarily. This is particularly appropriate on systems containing confidential business data, source code, legal documents, private communications, or privileged accounts.
Those who keep Muse installed should reduce its permissions to the minimum necessary. Access to Mail, Messages, Calendar, Notes, browser sessions, and broad file locations should not remain enabled merely because it might be useful later. Fewer approved resources leave fewer resources available to an attacker who gains control of the agent.
Frequently Asked Questions
5 questions
1What is the Meta Muse zero-day?
The Meta Muse zero-day is an unpatched macOS vulnerability disclosed by security researcher Patrick Wardle. It allows an unprivileged local process to change an undocumented dictationUrl preference, redirecting dictated Muse prompts and associated authentication material to an attacker-controlled server. That server may capture prompts or inject instructions into the agent.