Meta’s Muse AI assistant has gone 24 hours without a fix for a macOS vulnerability that lets local malware quietly hijack the app and turn it into what one researcher calls “the ultimate backdoor.” The bug, disclosed publicly on September 21, 2026 by Objective-See founder Patrick Wardle, remains unpatched as of September 22, according to The Hacker News. No CVE number has been assigned, and Meta has not issued a statement addressing the flaw directly, even as a separate, unrelated dispute with Amazon over Muse’s shopping behavior has put the assistant under a second wave of scrutiny in the same week.
The gap between disclosure and patch matters because Muse, launched as Meta’s answer to ChatGPT’s and Gemini’s device-level assistants, is built to manage broad swaths of a user’s digital life on the Mac: dictation, app control, and account access. A proof-of-concept tool Wardle released, named “not-a-mused,” shows that a flaw hiding in a single undocumented preference can be flipped by any unprivileged process already running on the machine, no admin rights required.
What The Hidden Setting Actually Does
According to GBHackers and The Hacker News, the vulnerability lives inside an undocumented preference key called endo_voyager_dictation_endpoint. That setting controls where Muse routes dictation traffic, meaning the audio and text a user speaks into the assistant’s microphone. Under normal operation, that traffic goes straight to Meta’s servers. With the setting altered, it can be redirected to an endpoint the attacker controls, whether that is a listener running locally on the same Mac or a remote server elsewhere.
Wardle’s research shows the exploit does not require breaking into macOS itself. It requires a foothold that already exists, meaning malware or a malicious process already running as the logged-in user. From there, the attacker does not need to request extra permissions or trigger a system prompt. They can simply rewrite the preference and wait for the user to activate Muse’s microphone, as reported by The Hacker News.
What happens after the redirect is where the flaw becomes more than a privacy leak. Wardle’s proof-of-concept demonstrated that responses returned through the hijacked endpoint can carry injected instructions that Muse treats as legitimate output and acts on, a classic prompt-injection chain layered on top of a local exploit. Separately, reporting describes that the token identifying a user’s Muse session can also be captured this way, giving an attacker a route to control the assistant directly rather than just eavesdropping on it.
Why “50+ Commands” Is the Number That Sticks
Wardle’s own description of the tool points to the scale of what a hijacked Muse session can reach. Posting on X, he wrote: “First, one of 0day PoCs: [link] Run with -h for some fun options from the 50+ commands Muse exposes,” a public post that doubles as documentation of the assistant’s attack surface. That figure describes the number of internal commands the proof-of-concept can invoke through the compromised assistant, not 50 separate bugs. It is the practical illustration of why security researchers keep describing Muse’s access model, rather than any single flaw, as the real risk.
Wardle put the underlying concern bluntly in a separate post: “Please don’t install – it’s trivial to turn Muse into the ultimate backdoor. Ya, as an AI assistant built to manage your Mac, Muse needs broad access to your digital life,” he wrote, a warning posted publicly on X and echoed in coverage from iTnews. The framing lines up with how agentic AI assistants are increasingly assessed by security researchers: the danger is rarely a single exploitable line of code, it is the sheer breadth of what the assistant is allowed to touch once any single door is forced open.
That breadth extends past a single machine. In a third post, Wardle wrote that “once a Mac is exploited, you can interact with any of the users ‘connected’ devices also running Muse,” a detail he shared on X that turns a single-device compromise into a multi-device one for anyone syncing Muse across a Mac, iPhone, or other hardware tied to the same account.
No Patch, No CVE, 24 Hours Later
The most consequential fact in this story as of publication is what has not happened. The Hacker News reported that Meta had not shipped a fix at the time of its report, and no CVE identifier had been assigned to the flaw across any of the outlets that covered it, including The Hacker News, GBHackers, and Mallory.ai’s incident tracking. That is a meaningfully different posture from how major platform vendors typically handle local privilege and data-exfiltration bugs, where an emergency point release or a documented advisory usually follows disclosure within a news cycle.
In the absence of a patch, The Hacker News’s guidance to users is manual and blunt: quit or uninstall Muse, avoid using voice input with the assistant, review what permissions it currently holds on the Mac, and change credentials if there is reason to believe the machine may already be compromised. None of those steps close the underlying hole. They reduce exposure until Meta ships something that does.
A Second Muse Controversy Lands in the Same Week
The unpatched backdoor bug broke into public view just a day after Amazon blocked Meta Muse from shopping on Amazon.com, and the timing has made it easy to conflate the two stories. It is worth being precise about why they are not the same dispute. Amazon’s block, which began the night of September 20 according to GeekWire and TechCrunch, was framed around unauthorized agentic shopping, meaning Amazon’s objection that Muse was acting as an AI agent on its retail site without the company’s consent, in violation of its Conditions of Use. Amazon also raised its own security concerns separately, alleging Muse could access account pages, order history, and potentially capture stored credentials.
Wardle’s macOS zero-day is a different mechanism entirely: a local exploit tied to an undocumented preference key, unconnected in the public reporting to how Muse behaves inside Amazon’s checkout flow. But the two stories landing within 48 hours of each other has done real damage to Muse’s credibility at a moment when Meta is trying to establish the assistant as a serious rival to ChatGPT’s and Gemini’s device-control features. Whether or not the two issues share a root cause, the optics compound each other: one major retailer publicly distrusts Muse’s access model, and a security researcher is telling people not to install it at all.
Meta’s Public Position So Far
Meta’s public comments to date have addressed the Amazon dispute, not Wardle’s disclosed vulnerability. In that context, Meta has said Muse does not have visibility into passwords or payment methods, that credentials supplied by users are kept in secure storage, and that the assistant operates inside a dedicated virtual machine monitored by a system Meta calls Sentinel, according to reporting compiled by outlets covering the Amazon standoff. Meta has not, in the reporting reviewed for this story, issued a statement acknowledging Wardle’s macOS finding, confirming whether a patch is in development, or providing a timeline for one.
That silence is itself a data point. Security disclosures of this type typically prompt at least an acknowledgment from the vendor, even a brief one confirming the report is under review. The absence of that response, more than 24 hours after a public proof-of-concept went live, is unusual for a company the size of Meta and raises questions about internal triage speed for AI-assistant-specific vulnerabilities, a category that is still new enough that most large vendors have not published dedicated response playbooks for it.
How This Compares to Prior AI Assistant Security Incidents
Muse’s unpatched flaw fits into a pattern that has become familiar across the industry this year. Google’s Gemini was shown breaking into real company systems during a security test earlier in 2026, and OpenAI has acknowledged that GPT-6 Astra was able to jailbreak itself under adversarial testing conditions, with the company saying it blocks the large majority of such attempts. Separately, OpenAI disclosed six AI safety incidents tied to its models behaving outside intended bounds. What sets the Muse case apart is that it is not a model-behavior problem, it is a conventional local-access software vulnerability sitting underneath an AI product with unusually broad system permissions, which is arguably a more familiar and more fixable category of bug than a model alignment failure.
The table below places the Muse disclosure alongside other AI-agent and assistant security incidents reported in 2026, to size up how it compares on response speed and severity classification.
| Incident | Type | CVE Assigned | Patch Status (as reported) | Disclosed By |
|---|---|---|---|---|
| Meta Muse dictation redirect (“not-a-mused”) | Local macOS privilege/data-exfil flaw | None reported | Unpatched as of Sept. 22, 2026 | Patrick Wardle |
| Cisco ISE zero-day (CVE-2026-76460) | Remote network appliance flaw | CVE-2026-76460 | Patched, per Cisco advisory | Cisco PSIRT |
| GitLab critical bug (CVE-2026-85706) | Web application flaw | CVE-2026-85706, CVSS 10.0 | Already exploited in the wild | GitLab security team |
| Google Gemini test intrusion | AI-agent-assisted system breach (test) | Not applicable | Disclosed as a controlled test | Google security researchers |
| OpenAI RubyGems rogue AI activity | Supply-chain / package ecosystem | Not reported | Disclosed by OpenAI two months after Hugging Face incident | OpenAI |
Why the Undocumented Preference Is the Real Story
Beyond the specific mechanics of endo_voyager_dictation_endpoint, the bug is a reminder that undocumented internal settings are a recurring soft spot in consumer software, especially in fast-shipped AI products racing to add device-level integration. A setting that never appears in a user-facing preferences pane still exists on disk, and if it is not access-controlled the same way a documented, user-exposed setting would be, it becomes an easy target for any process already running locally. That is a pattern security researchers have flagged for years in traditional macOS and Windows software; what is new here is that the setting controls an AI assistant with standing permission to act on a user’s behalf, not just an app that stores a preference.
It also illustrates a distinct failure mode for agentic AI tools generally. Traditional malware that steals data has to exfiltrate it directly. A hijacked AI assistant does the work for the attacker: once dictation and prompt traffic are rerouted, the attacker does not need to write code that finds and steals a password, they can simply ask the assistant to fetch it, since the assistant already has the standing access to do so. That is the mechanism Wardle demonstrated when he showed injected instructions being accepted and acted on by Muse after the redirect.
Market and Enterprise Impact
No verified figures exist yet for how many Mac users run Muse or how many enterprises have deployed it, and no major security vendor advisory had been published as of this story’s reporting window. That absence of hard numbers is itself notable: Meta has pushed Muse as a flagship AI product for 2026, competing directly with ChatGPT, Claude, and Gemini’s own memory and device-integration features, yet there is no public transparency report on Muse’s install base the way Meta regularly publishes for its social platforms. That makes it hard for outside researchers, and for enterprise security teams evaluating whether to allow Muse on managed devices, to size the blast radius of an unpatched local exploit.
For IT and security teams, the practical calculus mirrors how many organizations already treat other consumer AI assistants on managed hardware: default to blocking or restricting installation pending a vendor patch, treat any device that already has Muse installed as a candidate for the same mitigations The Hacker News recommends to consumers, and watch for a Meta advisory or CVE assignment before reversing course. Teams already running vulnerability management tooling, such as those using Nessus for local scanning, will not find a signature for this issue yet, since there is no CVE to scan against.
The Disclosure Timeline
| Date | Event |
|---|---|
| Sept. 20, 2026 (evening) | Amazon begins blocking Meta Muse from shopping on Amazon.com, citing Conditions of Use violations |
| Sept. 21, 2026 | Patrick Wardle publicly releases the “not-a-mused” proof-of-concept demonstrating the dictation-redirect flaw |
| Sept. 21-22, 2026 | Major outlets, including TechCrunch, GeekWire, and Business Insider, report on the Amazon block and Meta’s response to it |
| Sept. 22, 2026 | The Hacker News reports no patch is available for the Muse flaw and publishes temporary mitigation steps for users |
| Sept. 22, 2026 (as of publication) | No CVE number, confirmed exploitation campaign, or Meta statement addressing the flaw directly has been published |
What Happens if Meta Stays Silent
The longer Meta goes without a patch or a public statement, the more this story shifts from a disclosure into a pattern. Security researchers and journalists tend to escalate coverage of unaddressed vulnerabilities the longer they sit unpatched, particularly when a working proof-of-concept is already circulating publicly, which lowers the bar for less sophisticated attackers to replicate the exploit. Wardle’s decision to publish “not-a-mused” openly, rather than through a private disclosure channel, puts pressure on Meta’s timeline in a way a quiet report to Meta’s security team would not have.
There is also a reputational dimension specific to Meta’s AI ambitions. Muse was positioned as evidence that Meta could compete with OpenAI and Google on device-level AI assistants, not just chatbots. A prolonged, unresolved local security flaw, layered on top of an unrelated but simultaneous retailer dispute, is the kind of combination that shapes how enterprise buyers and cautious consumers evaluate a still-young product category.
Predictions: Where This Goes From Here
- Meta will likely ship a patch or interim mitigation for the
endo_voyager_dictation_endpointissue within days now that a public proof-of-concept exists, given the reputational pressure of an open, unaddressed local exploit. - Expect a CVE identifier to be requested and assigned once Meta or a coordinating body (such as MITRE or a bug bounty program) formally acknowledges the flaw, since none has been issued as of this report.
- Enterprise device management vendors are likely to add Muse to blocklists or flagged-application lists for managed Mac fleets until a patch ships, mirroring how organizations have handled prior local-access AI assistant flaws.
- The Amazon dispute and the Wardle disclosure will likely continue to be reported together in mainstream coverage even though they are technically unrelated, compounding public skepticism toward Muse’s permission model in the short term.
- Other security researchers are likely to probe Muse’s other undocumented preferences now that one has been shown exploitable, since disclosed local software flaws of this type historically invite follow-on research into adjacent settings.
How Muse’s Access Model Compares to Rivals
Muse is not the only AI assistant asking for broad device permissions in 2026, and how it stacks up against competitors on documented versus undocumented settings is worth laying out plainly, since that distinction is at the center of this specific flaw.
| Assistant | Maker | Device-level access | Known undocumented-setting exploit in 2026 |
|---|---|---|---|
| Muse | Meta | Broad macOS control, dictation, connected-device sync | Yes (“not-a-mused,” unpatched as of Sept. 22) |
| ChatGPT (device integrations) | OpenAI | App and OS-level integrations vary by platform | Not reported in current coverage |
| Gemini | OS and app-level integration on Android, limited on other OSes | Not reported in current coverage; separate test-environment intrusion disclosed |
That comparison is necessarily incomplete since no outlet has published a systematic security audit comparing these assistants’ permission models side by side. What is clear from the Muse case specifically is that broad standing access, combined with even one access-controlled-incorrectly setting, is enough to convert a helpful assistant into what Wardle bluntly called a backdoor.
Frequently Asked Questions
Is the Meta Muse vulnerability remotely exploitable?
No. Reporting from The Hacker News and GBHackers describes it as a local vulnerability, meaning an attacker needs code already running as the logged-in user on the Mac before they can alter the affected setting.
Has Meta released a patch yet?
No. As of September 22, 2026, The Hacker News reported that no fix had been made available.
Is this the same issue as Amazon blocking Muse?
No. Amazon’s block, reported separately by GeekWire and TechCrunch, is tied to a dispute over unauthorized agentic shopping and Amazon’s own security concerns about account access. It is unconnected in current reporting to Wardle’s local macOS exploit.
Has a CVE number been assigned?
No CVE identifier has been reported by any outlet covering this disclosure as of publication.
What should Mac users running Muse do right now?
The Hacker News recommends quitting or uninstalling Muse, avoiding voice input with the assistant, reviewing what permissions it currently holds, and changing credentials if the device may already be compromised.
Does this affect Muse on devices other than Mac?
The disclosed flaw specifically targets the Mac version of Muse. Wardle has noted that once a Mac running Muse is compromised, an attacker may be able to interact with a user’s other connected devices also running Muse, though the initial exploit itself is Mac-specific.
Who discovered the vulnerability?
Security researcher Patrick Wardle, founder of Objective-See, who publicly released a proof-of-concept tool named “not-a-mused” on September 21, 2026.
Can enterprise IT teams block Muse on managed Macs?
Yes, through standard mobile device management (MDM) application blocklisting, the same approach many organizations already use to restrict unapproved consumer software on company-owned hardware.