Meta ha corretto con un hot-fix una vulnerabilità zero-day individuata in Muse, il nuovo agente AI personale dell’azienda, dopo la divulgazione pubblica del problema da parte del ricercatore di sicurezza Patrick Wardle. La falla consentiva a un processo locale privo di privilegi particolari di modificare il comportamento dell’applicazione Muse per macOS e reindirizzare verso un endpoint controllato dall’attaccante il traffico generato dalla funzione di dettatura. Wardle aveva reso pubblica la vulnerabilità il 21 settembre 2026, avvertendo gli utenti di non installare Muse e pubblicando contestualmente un proof of concept su GitHub chiamato “not-a-mused”. La cronologia del repository mostra tre commit, tutti datati 21 settembre, relativi alla creazione del progetto, all’aggiunta dello script notamused.py e all’aggiornamento del README. Nelle prime ore del 22 settembre il ricercatore ha poi confermato che Meta aveva applicato rapidamente una correzione, spiegando successivamente che avrebbe presentato ulteriori dettagli e altre vulnerabilità durante la conferenza Objective by the Sea v9.
Il problema era legato a un’impostazione non documentata di Muse denominata endovoyagerdictation_endpoint, modificabile localmente senza richiedere privilegi amministrativi. Nel normale utilizzo, quando l’utente preme il pulsante del microfono e detta un prompt, Muse invia l’audio e il relativo contenuto verso l’infrastruttura prevista dall’applicazione; alterando questo parametro, invece, un malware o un processo eseguito con i privilegi del normale utente poteva sostituire l’endpoint legittimo con un server controllato dall’attaccante. Il proof of concept sviluppato da Wardle sfruttava proprio il flusso di dettatura attivato dal pulsante del microfono e implementava solo una parte degli oltre 50 comandi messi a disposizione da Muse, ma era sufficiente a dimostrare conseguenze molto più ampie della semplice intercettazione dell’audio. L’attaccante poteva infatti acquisire i prompt pronunciati dall’utente, introdurre istruzioni proprie nel flusso di interazione dell’agente, sottrarre il materiale di autenticazione utilizzato da Muse e sfruttare indirettamente tutti i permessi che l’utente aveva già concesso al sistema. In questo scenario, quindi, l’accesso accordato a Muse poteva trasformarsi nell’accesso disponibile per l’attaccante.
L’attacco richiedeva inizialmente la possibilità di eseguire codice come utente locale sul Mac compromesso e non costituiva quindi, nella sua forma di base, una compromissione remota autonoma. Il rischio principale derivava però dall’amplificazione dei privilegi operativi ottenibile attraverso l’agente AI. Un malware locale tradizionale può essere limitato dalle autorizzazioni del processo che lo esegue, mentre Muse può disporre di accesso autorizzato a servizi, account e dati che l’utente gli ha espressamente affidato. Wardle ha indicato tra gli effetti pratici della compromissione la sottrazione dell’audio dettato, l’iniezione di prompt che Muse avrebbe potuto considerare attendibili ed eseguire, il furto del token di autenticazione necessario per controllare direttamente l’agente e l’accesso alle risorse collegate, comprese potenzialmente comunicazioni, posta elettronica e informazioni finanziarie. Il ricercatore ha descritto la vulnerabilità come semplice da sfruttare e ha chiesto pubblicamente una correzione immediata.
Le conseguenze non erano inoltre limitate al singolo computer sul quale veniva eseguito il codice malevolo. Wardle ha spiegato che, dopo la compromissione di un Mac, l’attaccante poteva interagire anche con gli altri dispositivi associati allo stesso utente sui quali Muse risultava attivo, arrivando a impartire operazioni al client Muse per iOS senza che l’utente ne fosse consapevole. Il ricercatore ha inoltre documentato l’esistenza di un vettore remoto basato su una tecnica in stile ClickFix: inducendo la vittima a eseguire un singolo comando, un attaccante remoto poteva portare il codice necessario sul sistema e ottenere un livello di controllo circoscritto all’ambiente Muse ma esteso a tutti i dispositivi Muse-enabled collegati all’account, compreso iOS. Questo secondo scenario manteneva quindi la necessità di un’azione iniziale dell’utente, ma permetteva di trasformare una singola esecuzione locale in una compromissione più ampia dell’ecosistema personale gestito dall’agente.
Muse era stato presentato da Meta l’8 settembre 2026 come agente personale progettato con un’architettura di sicurezza costruita sull’ipotesi che il sistema AI potesse essere sottoposto ad attacco. Il daemon dell’agente e gli strumenti che può utilizzare vengono eseguiti all’interno di una cella runtime systemd-nspawn separata dal sistema host, mentre un componente distinto sul lato host, chiamato Sentinel, rappresenta l’unica autorità incaricata di concedere permessi alle azioni effettuate tramite i connector e di controllare tutto il traffico di rete in uscita. Le credenziali dei servizi collegati vengono conservate nella macchina virtuale dell’utente e Sentinel effettua l’inserimento just-in-time delle credenziali al confine di rete, con l’obiettivo di impedire all’agente e al modello sottostante di visualizzare direttamente i token reali. Meta ha inoltre aperto il programma bug bounty di Muse a tutti i ricercatori, prevedendo ricompense fino a 300.000 dollari per segnalazioni valide e fino a 130.000 dollari per attacchi di prompt injection in grado di compromettere un singolo utente.
Ulteriori protezioni documentate da Meta prevedono l’isolamento della macchina virtuale assegnata a ciascun utente rispetto a quelle degli altri utilizzatori di Muse e l’impiego di un Secure Credentials Store per nomi utente, password e altre informazioni sensibili. Attraverso questo meccanismo Muse può completare un’azione precedentemente autorizzata senza che il modello AI debba conoscere direttamente la password utilizzata. Per alcune operazioni considerate particolarmente rilevanti, come l’invio di un’email o l’esecuzione di un acquisto, il sistema è inoltre progettato per chiedere una conferma esplicita all’utente. I controlli principali relativi ai permessi e alla sicurezza sono mantenuti separati dal modello linguistico, in modo che la protezione non dipenda esclusivamente dalla capacità dell’AI di riconoscere autonomamente un’istruzione malevola o una prompt injection. Meta ha comunque riconosciuto fin dalla presentazione del sistema che Muse non può essere considerato immune agli attacchi e che la prompt injection continua a rappresentare un problema non risolto per l’intero settore.
La società prevede inoltre di introdurre entro il 2026 una versione denominata Muse Confidential VM, progettata per impedire in maniera verificabile e crittografica che la stessa Meta possa accedere ai dati presenti nella macchina virtuale dell’utente. La vulnerabilità corretta in seguito alla segnalazione di Wardle evidenziava però un punto differente rispetto alla protezione interna dei token o all’isolamento del runtime: il problema si trovava infatti nel percorso attraverso il quale un componente locale poteva modificare la destinazione della dettatura e inserirsi a monte dell’interazione con l’agente. Di conseguenza, pur in presenza di un’architettura che separa modello, credenziali, permessi e ambiente host, un’impostazione locale modificabile senza privilegi poteva offrire a un malware già presente sul sistema un punto di ingresso capace di sfruttare le autorizzazioni molto più ampie attribuite a Muse. Meta ha corretto la falla immediatamente dopo la divulgazione pubblica del 21 settembre, con la conferma dell’hot-fix arrivata il giorno successivo.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)