"Each person stays in control of their Muse and decides how much access it gets," the ad biz declared — a claim security researcher Patrick Wardle now says a local zero-day in Meta's Muse macOS app undermines.
Patrick Wardle's not-a-mused proof-of-concept
Wardle, founder of the nonprofit Objective-See, published a proof-of-concept called not-a-mused that demonstrates what he describes as a local zero-day in Meta's Muse macOS app. According to the project repo and Wardle's account, Muse includes an undocumented configuration setting named endo_voyager_dictation_endpoint that an attacker able to run local code can modify without special privileges. By changing that setting, an unprivileged local process can redirect Muse's dictation traffic to an attacker-controlled endpoint.
How the flaw can expose dictated audio, prompts, and credentials
Wardle says the redirected dictation traffic could expose audio and the prompts Muse sends to its backend AI model. In his write-up he warns the flaw could enable prompt injection, the theft of authentication material, and abuse of whatever access the user has already granted to Muse. The vulnerability is not exploitable remotely; it requires the ability to execute code locally on the affected Mac. Still, Wardle frames the bug as essentially a privilege-escalation issue: it allows local malware to gain broader access than it would otherwise have.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scramblemacOS controls, EDR, and the risk of a single point of failure
Wardle contrasted the Muse issue with macOS security mechanisms, saying Apple has "done a really good job" with its Transparency, Consent, and Control (TCC) framework and with privilege separation. He warned, however, that AI applications can undo those barriers because they request or require extensive access to data and tools. "They're super convenient and super empowering. But they have so much access if you configure them to be useful. They basically could do anything on your computer," he said, arguing such agents can become a "single point of failure that breaks operating system security controls."
On the endpoint-detection front, Wardle noted improvements: EDR products have gotten better on macOS in part because code signing makes it easy to identify processes that are not notarized. Yet he cautioned that, when AI agents are granted broad permissions, an EDR cannot easily tell whether a command is coming from the user, from an agent, or from an attacker.
Meta's design choices and Apple's on-device dictation API
Wardle asserted that Apple provides an on-device local dictation capability, and said that "if Meta chose to use that API, this vulnerability would not exist." He suggested Meta opted not to use Apple's service, "presumably because it wants access to that data," adding, "I think some of their greediness for user data kind of opens the door, makes a bigger attack surface." He also questioned whether AI companies are running their own models against their products for security checks: "You know these AI companies have really great AI models for finding bugs," he said. "Are they not running them against [their own apps]? Is the priority not the security of their own apps?"
What this means for technologists, enterprises, and end users
- Technologists and security teams: Wardle's findings highlight a specific attack vector — an undocumented endpoint setting — that defenders should audit in AI clients and factor into threat models for local code execution on macOS.
- Enterprises and EDR operators: The report underscores a tension Wardle describes between broad agent permissions and the limits of EDR telemetry; defenders may face challenges distinguishing legitimate agent actions from attacker activity when an agent has extensive access.
- End users and product teams: The episode stresses Wardle's point that apps asking for broad access can concentrate risk. Choosing on-device services where available — Wardle cited Apple's local dictation API as an example — may reduce exposure.
Meta did not immediately respond to a request for comment, and Wardle's proof-of-concept remains a public demonstration of how a local compromise can pivot through an undocumented configuration to capture dictation traffic. The core, practical question his work leaves on the table is narrow and specific: when an AI client asks for sweeping access, who inside the product team has responsibility for mapping that access to a secure design — and are they using the same tools and models they tout for finding bugs?
