Can Local Malware Hijack Meta Muse And Steal Your Voice Prompts?

September 22, 2026

Meta Muse's Mac client reportedly lets local malware redirect dictation, capture voice prompts, and inherit an agent's broader permissions.

Yes—according to a newly published proof of concept, malware or another process already running as the logged-in Mac user can redirect Meta Muse's dictation traffic to an attacker-controlled server. That could expose dictated prompts, let the attacker alter what Muse hears, and reveal authentication material that may be used to control the Muse account.

The critical limitation belongs in the first paragraph: this is not a remote attack that breaks into a clean Mac by itself. Security researcher Patrick Wardle's not-a-mused disclosure says an attacker must already be able to execute code as the local user. The concern is what happens next. A low-privilege foothold may be able to inherit the much broader access a user deliberately gave a personal AI agent.

That distinction is the real story. Muse is meant to work across files, voice, connected services, purchases, messages, calendars, and other devices. If a local process can quietly redirect a trusted agent's sensitive endpoint, the security boundary is no longer just “can malware read this Mac?” It becomes “can malware use the agent as the user?”

Who This Is For

This guide is for people asking:

The answers require separating the demonstrated client-side weakness from possible follow-on abuse, and both from claims that have not been independently confirmed.

What Is Confirmed

The researcher published a working local proof of concept

On September 21, 2026, macOS security researcher Patrick Wardle published the not-a-mused repository. Its documentation describes a local zero-day in the Muse Mac client and identifies an undocumented setting named endo_voyager_dictation_endpoint.

Wardle says an unprivileged local process can change that setting without special permissions. Muse then trusts the replacement address as the destination for dictation traffic.

The repository is explicit about the prerequisite: an attacker must already be able to execute code as the logged-in user. That could mean malware, an unwanted app, or a command a person was tricked into running. The published issue is not an unauthenticated internet exploit against every Muse installation.

Redirected dictation can expose prompts and authentication material

When a Muse user presses the microphone button and dictates a prompt, the client sends traffic to the configured dictation endpoint. In the proof of concept, changing that endpoint sends the request to infrastructure controlled by the attacker.

Wardle lists four potential outcomes:

Ars Technica's technical report says the redirected request included the token that authenticates the user's Muse account. Ars reports that Wardle used the resulting control in demonstrations involving file writes and photographs.

The safest phrasing is still “the researcher reports and demonstrates,” not “every attacker can already steal every Muse user's data.” The public material establishes a concrete attack path; it does not establish widespread exploitation.

The attack can change what the agent receives, not only listen

A malicious endpoint does not have to stop after collecting a voice request. Ars describes a proxy-style path in which the attacker's server receives the user's dictated prompt, adds a malicious instruction, and forwards the changed request onward.

That matters because the visible action begins with something ordinary: the user clicks Muse's microphone and speaks. The attacker does not necessarily need a second approval at the exact moment the voice traffic is redirected.

Whether a modified prompt can complete a sensitive action depends on the action, the user's permissions, Muse's current confirmation rules, and other controls. Meta's own Muse launch announcement says the agent asks before actions such as sending email or making a purchase. A prompt-injection path is therefore not proof that every consequential action becomes silent.

The potential blast radius comes from permissions Muse already has

Meta describes Muse as an agent that can send email, book travel, open a browser, fill forms, negotiate, make purchases, remember personal details, work after the app closes, and interact through connected services. It says each user decides how much access Muse receives.

Those abilities are the value proposition—and the reason a compromised agent can be more useful to an attacker than a small standalone app.

An ordinary process may lack macOS permission to use the camera, microphone, files, location, or calendars. If that process can control a trusted agent that already has those permissions, the agent can become an access amplifier. Wardle summarizes the risk plainly in the repository: Muse's access can potentially become the attacker's access.

This is not a traditional privilege-escalation claim that gives malware root or kernel access. It is a trust and authority escalation: a weakly privileged process may be able to steer a much more trusted application.

Reporting describes a cross-device demonstration

iTnews reports that Wardle demonstrated requests involving a linked iPhone's location and a Bluetooth scan. It also notes an important boundary: messaging prepared a draft rather than silently sending it.

That distinction helps calibrate the risk. A compromised Muse session may reach beyond the Mac because the account connects multiple devices and services, but the exact action available without confirmation is capability-specific. One successful location or device query does not prove unrestricted, invisible control of every linked phone function.

Meta's public launch claims make the conflict unusually sharp

Meta launched Muse on September 8 as a personal agent “built from the ground up” to be safe, secure, and private. The company says Muse runs in a dedicated Secure VM, keeps credentials away from the main agent, uses a separate Sentinel to govern connector actions and network egress, asks for approval before sensitive actions, and provides an audit trail.

Those controls concern the cloud agent, connected services, and agent actions. Wardle's report concerns a different boundary: whether another local process on the Mac can rewrite where the client sends dictation traffic.

A secure cloud execution environment does not automatically protect a compromised client before data reaches that environment. Endpoint configuration, local IPC, update integrity, browser sessions, and authentication tokens remain part of the complete system.

How The Reported Attack Chain Works

The attack is easier to understand as five separate steps:

  1. Local foothold: An attacker first gets code running as the logged-in Mac user. The Muse issue does not supply this initial foothold.
  2. Endpoint change: That local code changes the undocumented dictation-endpoint setting without elevated privileges.
  3. User trigger: The user presses Muse's microphone button and dictates a normal request.
  4. Traffic interception: The request reaches the attacker-controlled endpoint, exposing the prompt and reportedly Muse authentication material.
  5. Agent abuse: The attacker may alter the prompt or use the captured session to request actions within the authority available to that Muse account.

Every step matters. Removing the local foothold prevents this chain. Protecting the endpoint setting would interrupt it. Binding authentication more narrowly could reduce reuse. Requiring confirmation for sensitive actions can limit consequences. Scoping connectors and device permissions can shrink the final blast radius.

Security is not one magic sandbox. It is a sequence of boundaries, and an attacker needs only one reliable path through each boundary that remains.

Why “The Mac Was Already Compromised” Is Not The Whole Answer

It is true that local code execution is serious before Muse enters the picture. A stealer can look for browser cookies, documents, cloud sessions, and other secrets. Users should not interpret not-a-mused as the first risk created by malware.

But “all bets are off” is too broad to be useful. Modern operating systems intentionally give different applications different permissions. A process that can run as a user may still be denied access to protected resources. Security teams rely on those boundaries to keep one bad app from automatically inheriting every capability of every good app.

An agent changes the economics. Users connect many sources and grant many permissions to one application because it needs broad context to act. If a weaker process can commandeer that application, the attacker may avoid building separate code for every protected resource or service.

The right question is not whether the Mac was already perfectly safe. It is whether Muse turns a limited local compromise into a larger account, connector, voice, and cross-device compromise.

Wardle's disclosure presents evidence that it can. The exact maximum blast radius remains under investigation.

What Is Still Unclear

Meta has not published a public advisory or patch statement found in this review

As of the September 22 research cutoff, the reviewed sources did not identify a Meta security advisory, CVE, affected-version range, fixed-version number, or formal mitigation for the reported setting.

Ars says Meta representatives did not answer its emailed questions. That is not proof that Meta has done nothing internally, and it is not a substitute for checking the current app version and official support channels. It means users do not yet have a public vendor document that closes the uncertainty.

Independent reproduction and full technical scope remain limited

Wardle published proof-of-concept code and reporting includes demonstrations. The reviewed material does not include an independent third-party reproduction with a complete matrix of Muse versions, macOS versions, account types, connector combinations, or action-confirmation states.

The disclosure says the proof of concept implements a subset of more than 50 commands exposed by Muse. That does not mean every command succeeds silently or that every user exposes the same command set.

No evidence of exploitation in the wild was found

The existence of a public exploit path raises urgency, but it does not establish that criminals used it before disclosure or have compromised ordinary Muse users now.

The reviewed sources did not provide an affected-user count, incident timeline, telemetry estimate, or forensic indicators tied to real victim systems. Treat the issue as a defensible exposure, not a confirmed mass breach.

The precise token scope and revocation behavior need vendor detail

Reporting says the redirected traffic can expose a token that controls the Muse account. Public sources reviewed here do not fully define that token's lifetime, device binding, revocation behavior, connector restrictions, or whether changing a password or signing out invalidates every captured copy.

Those details determine whether interception enables one short request or persistent account control. Until Meta documents them, users should not assume either the shortest or worst possible lifetime.

The relationship to Secure VM controls needs a complete vendor explanation

Muse's Secure VM, Sentinel, credential surrogate system, taint tracking, confirmations, and audit trail may still limit particular actions. The reported client flaw does not prove those controls are fake or universally bypassed.

It does show that cloud-side controls are only part of the data path. Meta still needs to explain which protections remain effective after client traffic is redirected and authentication material is exposed.

What This Does Not Prove

The disclosure does not prove that:

It also does not turn a client-security flaw into evidence about Meta's model-training practices. OpenVeil's earlier guide, Meta Calls Muse A Private AI Agent. Can Meta Still Access Your Data?, covers the separate provider-access, training, retention, and Confidential VM questions.

The new issue is narrower and concrete: a local process may be able to redirect trusted dictation traffic and use the authority already concentrated in the agent account.

What Muse Users Should Do Now: The VOICE Check

Until Meta publishes an authoritative fix and scope statement, use VOICE to reduce avoidable exposure.

V — Verify the app and vendor status

Record the Muse app version, macOS version, installation source, and update status. Check Meta's official support and security channels for an affected-version range or patched release rather than relying only on social posts or an app-store “up to date” label.

If an organization manages Macs, inventory installations centrally and decide whether the app should remain enabled before the vendor publishes a clear disposition.

O — Only grant authority the current task needs

Review Muse's access to files, microphone, camera, location, calendars, messages, email, shopping, cloud storage, social accounts, and linked devices. Remove connectors and operating-system permissions that are not necessary now.

Permission reduction matters even if the flaw remains. An attacker who inherits a narrower agent inherits less.

I — Isolate high-sensitivity work

Do not dictate secrets, recovery codes, authentication details, regulated data, private legal strategy, or other high-impact material into an app whose dictation path is unresolved.

For sensitive workflows, separate general drafting from systems that can take actions. Avoid combining broad connected-account authority with the most sensitive content unless the task genuinely requires both.

C — Cut sessions and connections after suspected compromise

If the Mac ran untrusted code or shows signs of malware, stopping dictation alone may not be enough. Disconnect sensitive services, sign out active sessions, review Muse's audit trail, and use official account-security controls to invalidate sessions where supported.

Rotate credentials through clean, trusted devices when compromise is plausible. A credential change performed on the same infected endpoint may simply be captured again.

E — Endpoint defenses still come first

Patch macOS and installed software, restrict untrusted applications and scripts, use reputable endpoint protection where appropriate, and investigate suspicious persistence or commands. The reported chain begins with local execution; preventing and detecting that foothold remains essential.

Do not treat an AI-agent confirmation prompt as a malware defense. Confirmations can limit agent actions, but they do not disinfect the Mac or prove that intercepted voice traffic stayed private.

Where OpenVeil Fits — And Where It Does Not

OpenVeil is a hosted, privacy-focused AI workspace for adults who want a narrower conversational surface. Normal private-chat history stays in the user's browser, and OpenVeil does not keep a normal server-side chat-history record for those sessions. OpenVeil also does not use documented prompts, uploaded files, images, audio, selected local-history context, or AI outputs to train foundation models.

That narrower design can be relevant when a user needs thinking, writing, search, file, voice, or media tools but does not need one persistent agent connected to email, shopping, a terminal, a phone, or the rest of a digital life.

OpenVeil is not fully offline, anonymous, zero-log, a Muse patch, a macOS security control, malware protection, a dictation-endpoint monitor, or a connected-account firewall. Active requests still require processing by OpenVeil and necessary AI, search, upload, hosting, routing, security, billing, and infrastructure providers. OpenVeil cannot protect secrets intentionally entered from an already compromised device.

The honest choice is about required authority and documented boundaries. If a task needs a broad autonomous agent, use the minimum connectors and permissions necessary, keep sensitive actions gated, and treat the client device as part of the security architecture. If the task only needs a conversation or a bounded tool, a narrower workspace can reduce how much authority is concentrated behind one session.

For related context, read what to check before trusting any AI privacy claim and private AI chat versus local AI.

You can also review OpenVeil's privacy policy before deciding whether its documented boundary fits your work.

Frequently Asked Questions

Can the Meta Muse zero-day remotely hack my Mac?

Not by itself. Wardle's disclosure says an attacker must already be able to execute code as the local user. The reported Muse weakness can then amplify that foothold by redirecting dictation and potentially inheriting the agent's account access.

Can not-a-mused steal voice prompts?

The proof-of-concept documentation says redirected dictation can capture audio or prompts. The trigger occurs when the user clicks Muse's microphone button and dictates a request.

Can an attacker change what Muse hears?

Potentially. A malicious proxy can receive the user's prompt, add or change instructions, and forward the modified request. Whether the resulting action succeeds silently depends on permissions and confirmation controls.

Does the attack expose a Muse login token?

Ars reports that the redirected request includes authentication material that can control the Muse account. Meta has not publicly documented the full token scope, lifetime, or revocation behavior in the materials reviewed here.

Can a compromised Muse reach a linked iPhone?

iTnews reports Wardle demonstrated requests involving a linked iPhone's location and Bluetooth scan. That is evidence of cross-device reach, not proof of unlimited invisible control over every phone function.

Has Meta patched the Muse vulnerability?

No public Meta advisory, CVE, affected-version range, or confirmed fixed version was found by the September 22, 2026 research cutoff. Check current official Meta support and security information before acting on that status.

Does Muse Secure VM stop this attack?

The reported flaw occurs in the Mac client's dictation configuration before the trusted request reaches Muse's cloud environment. Secure VM and Sentinel controls may still constrain particular actions, but they do not by themselves prove that locally redirected voice traffic or exposed authentication material is safe.

Should I uninstall Muse?

That depends on the permissions you granted, the sensitivity of connected data, the device's risk, and your tolerance for an unresolved client flaw. A cautious user can pause use, remove sensitive connectors, and wait for a vendor advisory. An organization should make a managed decision based on inventory and current official guidance.

Is OpenVeil immune to malware on my computer?

No. OpenVeil does not protect a compromised endpoint. Its relevant difference is a narrower hosted chat workspace with browser-local normal chat history and no foundation-model training on documented user inputs and outputs, not a guarantee against local malware.

Bottom Line

The Meta Muse report is serious because it joins two risks that are usually discussed separately: a local client weakness and an AI agent with broad connected authority.

What is confirmed is narrow but important: Wardle published a local proof of concept showing that unprivileged code running as the user can change an undocumented Muse dictation endpoint. The redirected path can capture prompts and, according to reporting, expose authentication material that may let an attacker steer the account.

What is not confirmed is equally important: this is not a remote break-in to a clean Mac, there is no evidence of mass exploitation, and the reviewed sources do not establish that every connected action bypasses confirmation or that every Muse user is affected in the same way.

Until Meta publishes a clear advisory and patched version, treat the Mac client, voice endpoint, account token, connected services, and linked devices as one security chain. Use VOICE: verify the version, only grant needed authority, isolate sensitive work, cut compromised sessions, and keep endpoint defenses first.

The larger lesson applies beyond Muse. The more permissions an agent collects, the more carefully its local client must defend every configuration value, token, and traffic destination. Convenience concentrates authority. Security has to protect the entire path to that authority—not only the model or the cloud sandbox.

Sources

Research cutoff: September 22, 2026. This is a newly disclosed local vulnerability claim with public proof-of-concept material and evolving vendor status. Recheck Meta's current security guidance, app release notes, and account controls before making a high-sensitivity deployment decision.

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.