Meta Muse AI Assistant Zero-Day on macOS: Detecting and Containing an AI Agent Turned Backdoor

Meta's Muse AI assistant for macOS ships with deep, user-granted permissions — screen access, input monitoring, file access, and the ability to act on connected accounts. A newly disclosed, unpatched vulnerability allows an attacker with the ability to execute a simple terminal command on a target Mac to hijack Muse and inherit that entire permission set, effectively converting a legitimate AI assistant into a fully authorized backdoor. There is no vendor fix as of this writing, so this is a containment-and-detection problem, not a patching problem. If Muse is deployed anywhere in your fleet, treat it as a pre-positioned surveillance capability until Meta ships a fix.

What Happened

Reporting by Malwarebytes describes a zero-day in Meta's Muse AI assistant on macOS that requires nothing more exotic than a terminal command to exploit. The core issue is architectural as much as it is a code bug: modern AI desktop assistants request sweeping macOS permissions — often including Accessibility, Screen Recording, Full Disk Access, and automation rights over other applications — so they can observe your screen, read your files, and act inside other apps on your behalf.

The Muse flaw lets a local attacker redirect or drive the assistant's agent functionality outside its intended control path. Because macOS's Transparency, Consent, and Control (TCC) framework grants permissions to the application, not to the intent, anything that successfully drives Muse inherits everything Muse was allowed to do:

• Screen capture and observation of everything the user sees, including password managers, internal dashboards, and confidential documents
• Monitoring of user input and activity via accessibility permissions
• Reading files the user can access, if Full Disk Access or Documents/Desktop permissions were granted
• Acting inside connected accounts — email, calendars, browsers, and any third-party app Muse was granted automation control over

This is the nightmare scenario security teams have been warning about since AI desktop agents began requesting god-mode permissions: the agent becomes a single, pre-authorized pivot point. An attacker doesn't need to bypass TCC, exploit the kernel, or bypass Gatekeeper — they just need to steer a process the user already trusted.

Technical Analysis

Affected Platform

• Product: Meta Muse AI assistant (macOS desktop client)
• Platform: macOS endpoints where Muse is installed and has been granted user-level permissions
• Patch status: Unpatched at time of disclosure — no fixed version is available. No CVE identifier has been published in the reporting at this time.

Attack Chain (Defender's View)

1. Initial access prerequisite: The attacker needs the ability to run a command on the target Mac. In practice this arrives via a malicious script, a trojanized installer or package (e.g., a poisoned Homebrew cask or npm postinstall), a rogue MDM profile, a compromised developer toolchain, or hands-on-keyboard access after an initial compromise. This is a post-execution privilege and capability amplifier, not a remote entry vector — but that distinction offers little comfort given how routinely attackers achieve code execution on macOS via social engineering and supply-chain tricks.

2. Hijack of the Muse agent: The exploit command drives Muse's assistant/agent functionality through an unintended path, causing the legitimate, signed, TCC-entitled Muse process to perform attacker-directed actions.

3. Permission inheritance: Because TCC grants attach to the Muse binary, the attacker gains effective use of Screen Recording, Accessibility, Full Disk Access, and Apple Events automation rights — all under the identity of a trusted, notarized Meta application that will sail past most reputation-based controls.

4. Surveillance and account control: With screen and input visibility plus automation rights, the attacker can harvest credentials and session tokens, read sensitive data as it's displayed, operate the user's email and browser sessions, and exfiltrate data through channels that appear to originate from legitimate user activity.

Exploitation Status

• PoC/technical details: Publicly described (terminal-command-level simplicity)
• Active exploitation: Not confirmed in the reporting, but the low barrier to execution makes opportunistic abuse highly likely — assume weaponization is imminent
• CISA KEV: Not listed at time of writing
• Vendor fix: None available

Why This Is Hard to Catch

The malicious activity executes inside a legitimate, signed process with legitimate entitlements. Traditional allowlisting, notarization checks, and signature-based tools will see nothing wrong. Detection must focus on behavioral anomalies: unexpected child processes spawned by Muse, unexpected screen capture or accessibility API usage patterns, automation events targeting browsers/password managers/email clients, and network egress inconsistent with Muse's normal telemetry.

Detection & Response

The rules below target the behaviors this exploitation produces, not the exploit string itself (which Meta and EDR vendors will likely signature quickly, and attackers will vary just as fast). Tune process names against your actual Muse installation path before deployment.

Sigma Rules

---
title: Muse AI Assistant Spawning Shell or Script Interpreter
description: Detects Meta Muse spawning shells or script interpreters, consistent with hijack of the assistant's agent functionality to execute attacker-directed commands.
status: experimental
references:
  - https://www.malwarebytes.com/blog/bugs/2026/09/metas-muse-ai-assistant-has-a-zero-day-that-can-turn-it-into-a-mac-backdoor
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/08
logsource:
  product: macos
  category: process_creation
detection:
  selection_parent:
    ParentImage|contains:
      - '/Muse.app/'
      - 'com.meta.muse'
  selection_child:
    Image|endswith:
      - '/zsh'
      - '/bash'
      - '/sh'
      - '/osascript'
      - '/python'
      - '/python3'
      - '/curl'
      - '/screencapture'
  condition: selection_parent and selection_child
falsepositives:
  - Muse updates or legitimate plugin workflows invoking script interpreters — verify against Meta documentation and baseline
level: high
---
title: Screen Capture or Accessibility Abuse Involving Muse Process
description: Detects macOS screen capture tooling or TCC-protected resource access initiated from or around the Muse process tree, indicating surveillance via inherited permissions.
status: experimental
references:
  - https://www.malwarebytes.com/blog/bugs/2026/09/metas-muse-ai-assistant-has-a-zero-day-that-can-turn-it-into-a-mac-backdoor
  - https://attack.mitre.org/techniques/T1113/
author: Security Arsenal
date: 2026/09/08
logsource:
  product: macos
  category: process_creation
detection:
  selection_cmd:
    CommandLine|contains:
      - 'screencapture'
      - 'CGWindowListCreateImage'
      - 'AXIsProcessTrusted'
      - 'tccutil'
  selection_context:
    CommandLine|contains:
      - 'muse'
      - '/tmp/'
      - '/var/folders/'
      - '-x'
  condition: selection_cmd and selection_context
falsepositives:
  - Legitimate screenshot utilities invoked by users; correlate with Muse process ancestry and user context
level: medium
---
title: Suspicious Automation of Browsers or Mail from AI Assistant Context
description: Detects AppleScript-based automation of browsers, Mail, or keychain-adjacent targets launched in the context of the Muse assistant, consistent with account takeover via automation rights.
status: experimental
references:
  - https://www.malwarebytes.com/blog/bugs/2026/09/metas-muse-ai-assistant-has-a-zero-day-that-can-turn-it-into-a-mac-backdoor
  - https://attack.mitre.org/techniques/T1059/002/
author: Security Arsenal
date: 2026/09/08
logsource:
  product: macos
  category: process_creation
detection:
  selection:
    Image|endswith: '/osascript'
    CommandLine|contains:
      - 'tell application "Safari"'
      - 'tell application "Google Chrome"'
      - 'tell application "Mail"'
      - 'tell application "Microsoft Outlook"'
      - 'do javascript'
      - 'keystroke'
falsepositives:
  - Legitimate user automation workflows and IT provisioning scripts — rare in most fleets; review per-user
level: high

KQL (Microsoft Sentinel / Defender for Endpoint on macOS)

Hunt for Muse spawning unusual children, automation tooling execution, and screen capture activity across your macOS fleet. Defender for Endpoint on macOS surfaces these in DeviceProcessEvents.

// Hunt 1: Muse process spawning shells, script interpreters, or capture tooling
let Lookback = 7d;
let SuspiciousChildren = dynamic(["zsh","bash","sh","osascript","python","python3","curl","screencapture","sqlite3","security"]);
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where InitiatingProcessFileName has "muse" or InitiatingProcessFolderPath has "Muse.app"
| where FileName in~ (SuspiciousChildren)
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, SHA256
| order by TimeGenerated desc;

// Hunt 2: Apple Events / osascript automation of browsers, mail, or UI keystrokes fleet-wide
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where FileName =~ "osascript"
| where ProcessCommandLine has_any ("tell application", "do javascript", "keystroke", "System Events")
| extend InitiatedByMuse = (InitiatingProcessFileName has "muse" or InitiatingProcessFolderPath has "Muse.app")
| project TimeGenerated, DeviceName, AccountName, InitiatedByMuse, InitiatingProcessFileName, ProcessCommandLine
| order by InitiatedByMuse desc, TimeGenerated desc;

// Hunt 3: TCC database tampering or permission inspection around Muse (defense evasion / recon)
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where ProcessCommandLine has_any ("TCC.db", "tccutil", "kTCCServiceScreenCapture", "kTCCServiceAccessibility")
| where DeviceName in (
    DeviceProcessEvents
    | where TimeGenerated > ago(30d)
    | where FolderPath has "Muse.app" or FileName has "muse"
    | distinct DeviceName)
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine;

Velociraptor VQL

Use this artifact on macOS endpoints to identify live Muse process trees with suspicious descendants and to enumerate which TCC permissions Muse currently holds — your blast-radius assessment in a single hunt.

-- Muse AI Assistant Abuse Triage: process tree + TCC permission inventory
LET procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
  FROM pslist()

LET muse_tree = SELECT * FROM procs
  WHERE Name =~ '(?i)muse' OR Exe =~ '(?i)Muse.app'

SELECT 'muse_process' AS Finding, Pid, Ppid, Name, CommandLine, Username, CreateTime FROM muse_tree
UNION ALL
SELECT 'suspicious_child' AS Finding, a.Pid, a.Ppid, a.Name, a.CommandLine, a.Username, a.CreateTime
FROM procs a JOIN muse_tree b ON a.Ppid = b.Pid
WHERE a.Name =~ '(?i)(zsh|bash|osascript|python|curl|screencapture|sqlite3|security)'

-- Enumerate TCC grants for Muse to quantify surveillance capability
SELECT FullPath, Line
FROM parse_lines(filename='/Library/Application Support/com.apple.TCC/TCC.db')
WHERE Line =~ '(?i)muse'

Note: reading TCC.db directly requires Full Disk Access for the Velociraptor client; alternatively query it via sqlite3 from an execve-capable artifact or collect the per-user ~/Library/Application Support/com.apple.TCC/TCC.db where permitted.

Containment Script (Bash)

Since no patch exists, the defensive play is to strip Muse's TCC grants and/or remove the application until Meta ships a fix. This script audits permissions and removes the assistant on managed endpoints. Test in your environment; tccutil resets require appropriate management context (MDM-delivered or root).

#!/bin/bash
# Security Arsenal — Meta Muse zero-day containment (macOS)
# Run as root or via your MDM. Test before fleet-wide deployment.

set -euo pipefail
LOG="/var/log/muse_containment_$(date +%Y%m%d_%H%M%S).log"
exec > >(tee -a "$LOG") 2>&1

echo "=== [1] Identifying Muse installation ==="
MUSE_APP=$(mdfind 'kMDItemCFBundleIdentifier == "com.meta.muse"' 2>/dev/null | head -n 1 || true)
if [ -z "$MUSE_APP" ] && [ -d "/Applications/Muse.app" ]; then
  MUSE_APP="/Applications/Muse.app"
fi

if [ -z "$MUSE_APP" ]; then
  echo "Muse not found on this host. Exiting."
  exit 0
fi
echo "Found Muse at: $MUSE_APP"
BUNDLE_ID=$(/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' "$MUSE_APP/Contents/Info.plist" 2>/dev/null || echo "com.meta.muse")
echo "Bundle ID: $BUNDLE_ID"

echo "=== [2] Terminating running Muse processes ==="
pkill -f "$MUSE_APP" 2>/dev/null || echo "No running Muse processes."

echo "=== [3] Revoking TCC permissions (user + system scope where permitted) ==="
for svc in ScreenCapture Accessibility ListenEvent SystemPolicyAllFiles AppleEvents Microphone Camera; do
  tccutil reset "$svc" "$BUNDLE_ID" 2>/dev/null && echo "Reset $svc for $BUNDLE_ID" || echo "Could not reset $svc (may require MDM)"
done

echo "=== [4] Removing application payload ==="
rm -rf "$MUSE_APP"
rm -rf ~/Library/Application\ Support/Muse 2>/dev/null || true
rm -rf ~/Library/Caches/com.meta.muse 2>/dev/null || true
rm -rf ~/Library/Containers/com.meta.muse 2>/dev/null || true

echo "=== [5] Verifying removal ==="
if [ ! -d "$MUSE_APP" ]; then
  echo "SUCCESS: Muse removed. TCC grants revoked where permitted."
else
  echo "WARNING: Muse still present — check for MDM-managed reinstall or tamper protection."
fi

echo "=== Containment complete. Log: $LOG ==="

For a less destructive option while you assess business impact, run steps 1–3 only: kill the process and revoke its TCC grants, leaving the binary in place but neutered.

Remediation & Hardening

There is no patch. Your remediation plan is about permission hygiene, containment, and architectural policy:

1. Inventory Muse exposure immediately. Query your MDM/EDR for Muse installations and, critically, for which TCC services it has been granted on each host. A Muse install with no Screen Recording or Accessibility grant is dramatically lower risk than a fully permissioned one.

2. Revoke or remove, don't wait. Either uninstall Muse fleet-wide or strip its Screen Recording, Accessibility, Full Disk Access, and Automation grants via tccutil or MDM TCC/PPPC profiles until Meta publishes a fixed version. Monitor Meta's official security advisories and the Malwarebytes post for patch availability.

3. Enforce PPPC policy via MDM going forward. Push Privacy Preferences Policy Control profiles that deny by default Screen Recording, Accessibility, and Full Disk Access for AI assistant applications. Never rely on users clicking "Allow" judiciously.

4. Establish an AI-agent application policy. Desktop AI agents that request surveillance-class permissions should require security review before approval — the same rigor you'd apply to remote access tooling, because functionally that's what they are.

5. Hunt retroactively. Run the KQL and VQL queries above over the last 30 days. Look specifically for Muse spawning shells, osascript driving browsers or Mail, and screencapture execution near Muse activity. Any hits warrant a full DFIR triage of the host, including credential rotation for accounts used on it.

6. Rotate credentials on suspected hosts. If anomalous Muse behavior is found on an endpoint, assume every credential, session token, and connected account touched on that machine is compromised — the attacker had screen and input visibility, which defeats most local secrets hygiene.

7. Watch the update channel. When Meta ships a fix, validate the update's authenticity (signed, delivered via official channel) before approving deployment — a publicized AI-assistant zero-day is prime material for fake-update social engineering.

The Bigger Lesson

This is the first wave of a structural problem, not a one-off bug. Desktop AI assistants are being granted permission sets that rival EDR agents and RMM tools — the two categories attackers already abuse most for exactly this reason. Every AI agent you approve is a pre-authorized execution and surveillance platform waiting for its hijack primitive. Treat AI assistant permissions like you treat RMM tooling: inventory it, MDM-control it, behaviorally monitor it, and have a kill switch ready.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub