Meta Muse Zero-Day Lets Malware Hijack the AI Agent
An undocumented macOS setting can redirect dictated prompts, expose authentication material, and turn Muse’s approved app access into an attacker’s tools.
Meta's Muse AI agent for macOS contains a zero-day vulnerability that allows unprivileged local malware to hijack the agent by redirecting its dictation traffic to attacker-controlled servers. Security researcher Patrick Wardle published a proof of concept showing that malware can modify an undocumented preference called dictationUrl to intercept prompts and authentication material, then inject malicious instructions that Muse executes using permissions the user previously granted.
The flaw requires an existing local foothold but needs no administrator privileges to exploit. As of September 21, 2026, Meta has not published a patched version. Users should disable Muse temporarily or minimize its application permissions until a fix is available, and can check for compromise using the command defaults read com.meta.muse dictationUrl.
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 dictationUrl preference.
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.
The 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.
Users and administrators can also check the preference involved in the public proof of concept:
/usr/bin/defaults read com.meta.muse dictationUrl
If the key is absent, macOS will normally report that it does not exist. An unexpected URL, especially one outside Meta’s infrastructure, is a strong warning sign. This check covers only the disclosed configuration change. It cannot prove that a Mac is free of malware or that Muse has not been attacked in another way. The command is an inference-based defensive check derived from the preference modified by Wardle’s proof of concept.
Anyone who finds a suspicious value should not assume that deleting it completes the cleanup. A still-running malicious process can restore the setting. The host should be examined for untrusted applications, login items, launch agents, browser extensions, downloaded executables, and other persistence mechanisms.
If compromise is suspected, users should also:
Quit Muse and revoke its macOS permissions.
Investigate and clean the Mac before entering new credentials.
Sign out of relevant Meta sessions from a trusted device.
Review recent messages, files, calendar actions, and account activity.
Install Meta’s update immediately once a fixed version is documented.
There is currently no public evidence in the cited disclosure of widespread exploitation in the wild. Caution is still warranted, especially now that the preference name and attack method are public.
Desktop AI Agents Need a Higher Security Baseline
Muse illustrates a structural problem facing desktop AI agents. These products combine natural-language input, account credentials, application automation, and access to private data within one process. A conventional utility might expose one folder or service; an agent is expected to move between them.
That concentration of authority changes how apparently small implementation mistakes should be evaluated. An undocumented URL override might be a low-impact debugging issue in a basic application. In an agent carrying authentication data and acting across personal applications, it becomes part of the security boundary.
Agent developers should assume that ordinary user-level malware will try to modify preferences, intercept local traffic, manipulate prompt history, and reuse granted permissions. Production builds cannot trust writable configuration simply because it lives inside the current user’s account.
Meta’s response will need to explain whether dictationUrl has been removed, why Muse sent authentication material to a configurable destination, and what prevents similar overrides elsewhere in the application. A version number and technical advisory would give users more confidence than a silent update.
Final Thoughts
The Muse zero-day is not a remote takeover of every Mac running Meta’s agent. It requires an attacker to obtain local code execution first, and the eventual damage depends on the permissions granted to Muse. Those limits matter, but they do not make the flaw minor.
Endpoint security is meant to stop one limited compromise from expanding into control over unrelated applications and data. Wardle’s proof of concept suggests Muse can do the opposite, converting an unprivileged process into a potential operator of the user’s AI agent.
The former Meta security manager’s refusal to use Muse is a personal threshold, not a technical verdict. For users deciding whether to run a newly released agent, waiting is the defensible choice. Meta should publish a fix, document exactly what authentication information was exposed, and explain how production service endpoints will be protected before users restore broad access to their files and communications.
Frequently Asked Questions
5 questions
1
What 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.
2
Can the Muse zero-day attack a Mac remotely?
No direct remote attack has been demonstrated in the published proof of concept. The attacker first needs a malicious or untrusted process running under the victim’s macOS account. The process does not need administrator or root privileges, however, and it can use Muse’s existing permissions to extend what the original malware can access.
3
What information could an attacker access through Muse?
An attacker could potentially reach any information or application the user has allowed Muse to access. Depending on the configuration, that may include local files, Mail, Messages, Calendar, Notes, browser activity, and dictated prompts. The vulnerability does not automatically provide access to resources that Muse itself cannot use.
4
Has Meta patched the Muse zero-day?
Meta had not publicly identified a fixed Muse version as of September 21, 2026. Patrick Wardle’s repository says the issue was shared with Meta, but the company’s public Muse security material did not yet contain a vulnerability advisory. Users should verify the release notes and Meta’s official security page before assuming a later update resolves it.
5
Should Mac users uninstall Meta Muse?
Security-sensitive users should stop running Muse until Meta documents a fix. Uninstalling the application or revoking its permissions reduces exposure, but users who suspect exploitation must also check the Mac for malware. Removing Muse alone will not eliminate the local process that changed its settings or prevent that malware from attacking other applications.
