Meta Rushes Out Muse Hotfix After Researcher Turns AI Agent Into a Local Attack Tool

Meta has patched a zero-day vulnerability in the Muse macOS application that could let locally running malicious code redirect the AI agent’s transcription workflow and misuse its access to the device.

Security researcher Patrick Wardle demonstrated that an attacker could manipulate Muse, reach resources associated with the victim’s Muse account, capture images, and write malicious files to disk. Some actions did not consistently produce a visible warning.

The flaw was not remotely exploitable by itself. An attacker first needed to execute code on the victim’s Mac under that user’s account, making the issue more useful after an initial compromise than as an entry point.

Meta issued a hotfix within hours of public reporting. However, the company has not disclosed an affected version range, a patched build number, or a CVE identifier.

An undocumented setting redirected cloud transcription

The weakness centered on an undocumented Muse configuration option controlling where the application sent transcription data for processing.

Muse relied on cloud infrastructure for dictation rather than performing the entire operation locally. Wardle found that an application running on the Mac could reportedly alter Muse’s undocumented settings, including the destination used for transcription processing.

Malicious code could therefore replace Meta’s legitimate server-side endpoint with infrastructure controlled by the attacker. That redirection created a path to intercept or manipulate Muse’s workflow and potentially expose access connected to the victim’s Muse account.

The problem was not cloud transcription alone. The exploit emerged from the combination of several design choices:

• Muse sent dictation outside the device for processing.
• Other applications could modify undocumented Muse settings.
• The agent retained access to device functions and local storage.
• The security boundary between configuration changes and user-authorized actions was insufficient.

Once Muse’s behavior had been redirected, the attacker could use the agent as a component of the intrusion rather than building every required capability into separate malware.

That distinction matters. A basic local implant might be able to co-opt an already trusted application, taking advantage of the permissions and account access that the user had granted to Muse.

Proof-of-concept attacks reached beyond transcription

Wardle created proof-of-concept attacks showing that the weakness could be used to make Muse take pictures and place malicious files on the Mac.

Those tests also indicated that users would not always receive a reliable visual alert. The absence of consistent notification could make malicious activity harder to distinguish from the agent’s normal background operations.

The demonstrated impact included:

• Redirecting transcription traffic to an attacker-controlled endpoint.
• Potentially accessing information associated with the Muse account.
• Invoking device capabilities available to the agent.
• Capturing images without dependable user notification.
• Creating attacker-chosen files on disk.

The findings do not mean the vulnerability independently delivered complete control of any internet-connected Mac. The attacker still needed an existing foothold, such as malware already running in the user’s session or software the victim had been induced to execute.

After that point, however, Muse could reduce the amount of functionality the attacker needed to implement directly. The AI agent effectively became a post-compromise resource.

Meta calls the practical risk low

Meta classified the issue as a local privilege-escalation vulnerability. David Singleton of Meta Superintelligence Labs said the practical risk to Muse users on macOS was “quite low” because exploitation depended on malicious code already running locally.

That assessment reflects the absence of a remote initial-access mechanism. A website, network request, or unauthenticated internet user could not exploit the vulnerability alone based on the known attack path.

The prerequisite does not eliminate the risk. Endpoint intrusions frequently involve multiple stages, and attackers routinely combine an initial execution technique with mechanisms that expand access, steal information, or abuse trusted software.

In this case, the value of the vulnerability was what it enabled after local execution. An attacker who had only limited malware running as the victim could potentially repurpose Muse’s account relationship, cloud workflow, file access, and camera-related capabilities.

No evidence of real-world exploitation has been reported. The known attacks were proof-of-concept demonstrations, not confirmed activity against Muse customers.

There is also no disclosed CVE identifier. Consequently, no CISA Known Exploited Vulnerabilities catalog entry or federal remediation deadline has been identified for this issue.

The hotfix arrived quickly, but version details remain absent

Meta released a hotfix within hours of the vulnerability becoming public through reporting by Ars Technica. Reporting on Meta’s response indicates that the update addressed the exposed configuration mechanism.

The rapid response reduces the window in which an unpatched installation remains vulnerable, but the lack of precise release information complicates verification. Meta has not publicly identified:

• The vulnerable Muse application versions.
• The first patched version or build.
• A CVE number.
• A complete technical advisory.
• File hashes or other indicators tied to exploitation.

Administrators cannot rely on a clearly defined version boundary from the available information. They should install the newest Muse update offered by Meta and confirm through their deployment tooling that the hotfix has reached every managed Mac.

Where that confirmation is not possible, organizations handling sensitive conversations, credentials, or proprietary material should consider suspending Muse until the patched application can be verified.

Defenders should hunt for behavior, not fixed indicators

There are no reported malicious domains, file hashes, or named campaigns associated with this vulnerability. Detection therefore depends on endpoint and network behavior.

Security teams should review Macs running Muse for outbound connections from the application to unexpected hosts, particularly traffic associated with transcription processing. Connections to infrastructure outside Meta’s expected environment warrant investigation.

Other useful signals include:

• Unexpected changes to Muse’s undocumented configuration values.
• Camera or image-capture activity involving the Muse process.
• Files created by Muse in unusual directories.
• Suspicious file creation near the time of Muse activity.
• Unauthorized child processes launched by or around Muse.
• Unusual network redirection associated with transcription sessions.
• Execution of untrusted applications under the affected user account.

A suspicious Muse event should also trigger a broader endpoint investigation. Because the exploit requires prior local code execution, evidence of attempted abuse may indicate that the Mac was already compromised through another route.

Application controls can reduce exposure by preventing unknown or unapproved software from running on systems where Muse is installed. Endpoint detection products should also monitor access to camera-related resources, changes to application configuration, and unexpected process-to-network relationships.

Muse’s growth raises the cost of weak agent isolation

The vulnerability appeared as Meta was promoting Muse’s privacy and security while positioning the product against other AI providers. Its launch reportedly generated substantial interest: estimated mobile downloads in the United States and Canada during Muse’s first 12 days exceeded ChatGPT’s estimated downloads across its corresponding initial 12-day period in those markets.

Meta’s stock also rose 11 percent on Monday. At the same time, Muse has faced scrutiny beyond the macOS flaw. Amazon reportedly blocked the agent from its e-commerce platform and alleged that Meta lacked authorization for the access.

The security issue exposes a broader architectural concern for AI agents. An assistant with access to cloud accounts, microphones, cameras, files, and external services can concentrate capabilities that attackers would otherwise need to assemble separately.

Strong isolation must therefore cover more than the model itself. Configuration interfaces, cloud destinations, inter-application permissions, account tokens, device capabilities, and user notifications all form part of the agent’s security boundary.

Meta’s hotfix closes the reported weakness. The incident nevertheless shows how a compromised endpoint can turn an AI assistant’s legitimate authority into an attacker’s shortcut.