Meta corrige un zero-day en Muse que permitía tomar el control del agente de IA en un Mac comprometido

Meta ha publicado un hotfix para una vulnerabilidad zero-day en la aplicación de Muse para macOS que permitía a un atacante manipular el agente de inteligencia artificial y aprovechar los permisos que el usuario ya le hubiera concedido. Hay una limitación fundamental: el atacante necesitaba poder ejecutar previamente código bajo la cuenta del usuario en el Mac. No era un fallo que permitiera tomar el control de Muse de forma remota desde Internet sin comprometer primero el equipo.

La vulnerabilidad fue descubierta por el investigador de seguridad especializado en macOS Patrick Wardle, fundador de Objective-See. Su prueba de concepto demuestra que un proceso local sin privilegios especiales podía modificar una configuración no documentada de Muse y redirigir el tráfico utilizado para la transcripción de voz hacia un servidor controlado por el atacante.

Desde ese punto era posible interceptar dictados, manipular los prompts que Muse recibía y obtener material de autenticación asociado a la cuenta. El riesgo resulta especialmente relevante porque Muse puede disponer, con permiso del usuario, de acceso a archivos, mensajes, calendario, notas, correo, cámara, micrófono y otros recursos del Mac.

Meta respondió al informe asegurando que ya ha distribuido un hotfix para Muse en Mac. La compañía también ha subrayado que el escenario requiere malware o código malicioso ejecutándose previamente en el ordenador, por lo que no debe interpretarse como una vulnerabilidad capaz de infectar un Mac directamente desde Internet.

El fallo permitía cambiar el servidor al que Muse enviaba la transcripción

El centro de la vulnerabilidad estaba en una configuración interna de la aplicación de Muse para macOS.

Wardle identificó un parámetro no documentado encargado de determinar el endpoint utilizado durante el procesamiento de dictados. El ajuste podía ser modificado por un proceso ejecutándose localmente con los permisos normales del usuario.

En condiciones normales, el audio o la información necesaria para la transcripción se dirige a infraestructura controlada por Meta.

El ataque permitía sustituir esa dirección por un endpoint administrado por el atacante.

Una vez realizado el cambio, el servidor malicioso podía colocarse en medio de la comunicación entre Muse y los servicios utilizados por el agente.

El atacante necesitaba tener ya código ejecutándose en el Mac

Esta condición es esencial para valorar correctamente el riesgo.

La prueba de concepto de Wardle indica expresamente que se trata de un ataque local. El atacante debe ser capaz de ejecutar código como el usuario que ha iniciado sesión en macOS.

Eso podría conseguirse, por ejemplo, mediante malware instalado previamente o mediante técnicas de ingeniería social que engañen al usuario para ejecutar un comando.

Pero la vulnerabilidad de Muse por sí sola no proporcionaba ese acceso inicial.

Meta ha insistido precisamente en este punto después de publicar el hotfix. David Singleton, responsable de producto en Meta Superintelligence Labs, explicó que para utilizar el fallo de forma maliciosa tenía que existir previamente código malicioso ejecutándose bajo la cuenta del usuario.

No era un exploit remoto contra cualquier usuario de Muse

Por tanto, no sería correcto describir el fallo como una vulnerabilidad que permitiera a un atacante conectarse desde Internet a cualquier Mac con Muse instalado y tomar el control del agente.

El escenario requiere dos etapas diferenciadas:

• Conseguir primero ejecutar código en el Mac de la víctima.
• Utilizar después la vulnerabilidad de Muse para aprovechar los permisos y conexiones que el usuario había concedido al agente.

La segunda etapa es lo que hace interesante el fallo desde el punto de vista de seguridad.

Un malware local ordinario puede tener acceso limitado por las protecciones de macOS. Si Muse ya ha recibido autorización para utilizar recursos más sensibles, secuestrar el agente podría proporcionar al atacante un camino adicional para utilizar esas capacidades.

Por qué Muse podía resultar especialmente atractivo para un atacante

La aplicación de Muse para Mac está diseñada precisamente para realizar acciones en nombre del usuario.

Meta explica que el agente puede trabajar con recursos locales como:

• Archivos.
• Messages.
• Calendar.
• Notes.
• Mail.

También puede utilizar otras capacidades dependiendo de los permisos concedidos y de los servicios que el usuario haya conectado.

La diferencia frente a comprometer una aplicación convencional es que un agente de IA ya dispone de lógica para interpretar instrucciones y encadenar acciones.

Wardle resume el riesgo de la vulnerabilidad de una forma sencilla: el acceso concedido a Muse podía terminar convirtiéndose en acceso aprovechable por el atacante.

El zero-day podía utilizarse para inyectar instrucciones en Muse

Redirigir el tráfico de transcripción permitía hacer algo más que escuchar lo que dictaba el usuario.

Un servidor malicioso situado en medio del proceso podía modificar la instrucción antes de que Muse la procesara.

Por ejemplo, una persona podía dictar una tarea aparentemente normal mientras el atacante añadía instrucciones adicionales al prompt recibido por el agente.

Esto convierte el fallo en un problema de integridad, no únicamente de confidencialidad.

El agente podía acabar ejecutando una instrucción que el propietario del Mac nunca había pronunciado.

Wardle demostró acciones como escribir archivos o utilizar la cámara

Durante sus pruebas, Wardle desarrolló diferentes demostraciones para mostrar hasta dónde podía llegar un atacante después de manipular el agente.

Entre las acciones demostradas se encontraban:

• Escribir archivos maliciosos en el equipo.
• Tomar fotografías utilizando recursos a los que Muse tuviera acceso.
• Manipular instrucciones enviadas al agente.
• Acceder al material de autenticación utilizado por Muse.

En determinados escenarios estas acciones podían producirse sin una advertencia evidente para el usuario.

Esto no significa que cualquier proceso instalado en macOS disponga normalmente de acceso directo a la cámara, mensajes o correo. El problema es precisamente que el atacante podía intentar reutilizar el nivel de acceso que Muse ya tenía autorizado.

También podía quedar expuesto el token de autenticación de Muse

La investigación señala otro elemento especialmente sensible: el material utilizado para autenticar la cuenta de Muse.

Al redirigir el endpoint de transcripción a un servidor controlado por el atacante, era posible obtener información de autenticación que podía permitir interactuar directamente con la cuenta.

Esto ampliaba el impacto potencial más allá del simple robo de un dictado concreto.

Una vez obtenido un token válido, un atacante podía intentar utilizar la sesión existente de Muse para enviar nuevas instrucciones aprovechando las conexiones ya autorizadas por el usuario.

La prueba de concepto se llama “not-a-mused”

Wardle publicó una prueba de concepto denominada not-a-mused para documentar el problema.

El investigador explica que Muse contiene un ajuste no documentado que controla el endpoint de dictado y que un proceso local podía cambiarlo sin necesitar privilegios especiales adicionales.

Su herramienta demuestra una parte de las funciones que podían aprovecharse después de redirigir el tráfico.

La prueba se publicó con fines de investigación de seguridad y para evidenciar el impacto del diseño utilizado por la aplicación.

El problema no dependía de obtener permisos de administrador

Otra característica relevante es que el proceso encargado de modificar la configuración de Muse no necesitaba necesariamente ejecutarse como root o administrador.

El requisito era poder ejecutar código como el usuario local.

Esto importa porque macOS utiliza diferentes sistemas de permisos para impedir que una aplicación corriente acceda directamente a recursos sensibles.

Un proceso sin autorización para utilizar la cámara o leer determinados datos no debería obtener automáticamente esos privilegios.

El problema de Muse creaba una posibilidad de amplificación de acceso: el código malicioso podía intentar dar instrucciones a una aplicación que sí había recibido permisos más amplios del usuario.

Un ataque ClickFix podía proporcionar el acceso inicial

Wardle también mostró cómo un atacante podría combinar el fallo con una técnica de ingeniería social del tipo ClickFix.

Estos ataques intentan convencer a la víctima de que copie y ejecute manualmente un comando en Terminal bajo el pretexto de solucionar un problema, completar una verificación o realizar alguna otra tarea aparentemente legítima.

Si la víctima ejecuta el comando, el atacante consigue el requisito previo que necesita la vulnerabilidad: código ejecutándose bajo la cuenta local.

Después podría modificar la configuración interna de Muse para redirigir su tráfico.

Esto vuelve a demostrar por qué no debe describirse el fallo como remoto. La ingeniería social o una infección previa sigue siendo necesaria para conseguir el primer punto de apoyo.

Meta ya ha publicado un hotfix

Después de hacerse pública la investigación, Meta confirmó que había distribuido un hotfix para la aplicación de Muse en macOS.

La compañía no ha presentado el incidente como una vulnerabilidad que permitiera comprometer remotamente un Mac y ha defendido que el riesgo práctico se reduce por la necesidad de contar ya con código malicioso en el dispositivo.

Aun así, publicó la corrección rápidamente.

Los usuarios de Muse en Mac deberían asegurarse de utilizar la versión más reciente disponible de la aplicación y no posponer las actualizaciones relacionadas con seguridad.

Meta no ha publicado una versión de parche específica en su declaración inicial

La respuesta pública de Meta confirma la existencia del hotfix, pero no proporciona en esa declaración inicial un número específico de versión que pueda utilizarse como referencia universal para comprobar manualmente el parche.

Por ese motivo, no conviene asociar el arreglo a una compilación concreta sin una confirmación adicional de Meta.

La recomendación práctica es mantener actualizada la aplicación oficial de Muse para macOS.

Por qué este fallo es distinto a una escalada tradicional de privilegios de macOS

Meta ha descrito el problema como un ataque local de escalada de privilegios, pero el mecanismo observado tiene un matiz importante.

El ataque no necesitaba explotar el kernel de macOS para convertir directamente a un usuario normal en root.

La ventaja obtenida provenía de poder controlar un agente que ya disfrutaba de permisos y acceso concedidos por la víctima.

En otras palabras, la “escalada” relevante consiste en pasar de un proceso local limitado a aprovechar indirectamente las capacidades de Muse.

Este patrón puede adquirir cada vez más importancia a medida que los agentes de IA reciban acceso a más aplicaciones y servicios.

El diseño de la transcripción en la nube fue clave

Wardle también ha cuestionado la decisión de procesar el dictado de Muse mediante un servicio remoto.

macOS dispone de mecanismos que permiten realizar determinadas tareas de dictado y transcripción localmente.

En Muse, el uso de un endpoint remoto creó un punto cuya dirección podía convertirse en objetivo de manipulación.

El problema se agravó porque ese endpoint podía ser modificado por código local sin una protección suficiente.

Al combinar ambos elementos, un atacante podía redirigir una comunicación sensible hacia infraestructura bajo su control.

La vulnerabilidad afecta a Muse para Mac

La investigación de Wardle se centra específicamente en la aplicación de Muse para macOS.

Meta ofrece también Muse para iPhone y Android, pero el fallo descrito se basa en el funcionamiento y la configuración del cliente para Mac.

No debe utilizarse esta investigación como prueba de que las aplicaciones móviles contienen exactamente la misma vulnerabilidad.

Sin embargo, Muse está diseñado para mantener continuidad entre dispositivos, lo que aumenta la importancia de proteger correctamente la cuenta y sus sesiones.

Muse para Mac tiene acceso especialmente amplio por diseño

Meta lanzó recientemente la versión de Muse para macOS con el objetivo de que el agente pueda realizar tareas directamente en el ordenador.

La compañía promociona funciones como organizar archivos, completar formularios y trabajar con Messages, Calendar y Notes después de recibir permiso del usuario.

Ese acceso es precisamente lo que hace útiles a los agentes personales, pero también eleva las consecuencias potenciales de cualquier vulnerabilidad que permita manipularlos.

Una aplicación sin acceso a información sensible tiene una superficie de impacto menor. Un agente cuya función es actuar sobre archivos, cuentas y aplicaciones necesita controles mucho más estrictos.

Qué deberían hacer ahora los usuarios de Muse en Mac

Meta asegura haber corregido el problema, por lo que la principal medida es mantener Muse actualizado.

Además, conviene:

• Instalar las actualizaciones oficiales de Muse para macOS.
• No ejecutar comandos de Terminal copiados desde páginas o mensajes desconocidos.
• Revisar qué permisos tiene concedidos Muse.
• Retirar accesos que ya no sean necesarios.
• Revisar aplicaciones desconocidas instaladas en el Mac.
• Mantener macOS actualizado.
• Investigar cualquier actividad inesperada del agente.

Estas medidas no sustituyen el parche, pero reducen la probabilidad de que un atacante consiga el acceso local previo necesario para explotar vulnerabilidades de este tipo.

Revocar permisos puede reducir el impacto de una futura vulnerabilidad

La utilidad de Muse aumenta a medida que obtiene acceso a más recursos, pero también lo hace su superficie de riesgo.

Si no necesitas que el agente utilice la cámara, mensajes, calendario u otra fuente determinada, mantener ese permiso deshabilitado limita lo que podría hacer una sesión comprometida.

El principio es el mismo que se aplica a cualquier otra aplicación: conceder únicamente los permisos necesarios para las funciones que realmente utilizas.

Un antivirus no sustituye la necesidad de corregir Muse

Como el ataque requiere ejecución local previa, las herramientas de seguridad pueden ayudar a detectar parte del malware utilizado para conseguir ese acceso.

Sin embargo, eso no convierte el parche de Meta en opcional.

Una vulnerabilidad dentro de una aplicación privilegiada debe corregirse en la propia aplicación, independientemente de las demás capas de defensa que tenga el sistema.

La defensa más sólida combina un Muse actualizado, macOS actualizado, permisos limitados y precaución frente a técnicas de ingeniería social.

El caso muestra un nuevo riesgo específico de los agentes de IA

La vulnerabilidad de Muse es interesante porque no se limita al patrón tradicional de “una aplicación vulnerable permite leer un archivo”.

Los agentes modernos reciben permisos para actuar activamente en nombre del usuario.

Pueden interpretar lenguaje natural, utilizar herramientas, abrir aplicaciones y encadenar diferentes pasos para alcanzar un objetivo.

Si un atacante consigue controlar la entrada que recibe uno de estos agentes, puede intentar convertir todas esas capacidades legítimas en herramientas para su propio objetivo.

Más permisos para el agente significan un mayor impacto potencial

El problema tampoco significa que los agentes de IA sean intrínsecamente inseguros, pero sí cambia el modelo de amenazas.

En una aplicación convencional, una vulnerabilidad suele estar limitada por las funciones de esa aplicación.

Un agente personal está diseñado para atravesar esos límites y coordinar múltiples aplicaciones y servicios.

Por ello, aspectos como la autenticación, el almacenamiento de tokens, la integridad de los prompts, el control de endpoints y los límites entre procesos adquieren una importancia mucho mayor.

Meta había presentado Muse con fuertes garantías de seguridad

Meta promociona Muse como un agente con controles de privacidad y seguridad incorporados y afirma que el usuario mantiene el control sobre los permisos concedidos.

El sistema utiliza además una máquina virtual dedicada para determinadas tareas web y aplica protecciones diseñadas para evitar acciones o divulgaciones no autorizadas.

El fallo encontrado por Wardle no demuestra que todas esas capas hayan quedado anuladas, pero sí muestra que la seguridad de un agente también depende de componentes aparentemente secundarios del cliente local, como la forma en que se configuran sus endpoints internos.

No hay que confundir este zero-day con una infección automática de los Mac

La conclusión más importante para los usuarios es doble.

Por un lado, la vulnerabilidad era seria porque permitía a código local manipular un agente con acceso potencialmente muy amplio y utilizar sus propios permisos contra el usuario.

Por otro, el Mac tenía que estar ya comprometido hasta el punto de permitir la ejecución de código bajo la cuenta de la víctima.

No existía un mecanismo demostrado por el que simplemente tener Muse instalado permitiera a un atacante remoto tomar el control del equipo desde Internet.

Meta ha cerrado el fallo, pero el modelo de riesgo seguirá siendo relevante

Meta ha reaccionado con un hotfix para Muse en macOS, por lo que este fallo concreto ya dispone de una corrección.

La investigación de Patrick Wardle deja, sin embargo, una cuestión más amplia para toda la industria: cuanto más acceso recibe un agente de IA para resultar útil, mayor es el impacto potencial si otro proceso consigue controlar las instrucciones que recibe o apropiarse de su sesión.

En el caso de Muse, un proceso local sin privilegios especiales podía modificar el destino utilizado por la transcripción, inyectar instrucciones y potencialmente aprovechar recursos previamente autorizados por el usuario.

Eso hace que la formulación correcta del incidente no sea que “Muse podía hackear remotamente un Mac”, sino que un Mac ya comprometido podía utilizar el zero-day de Muse para ampliar considerablemente lo que un atacante podía hacer a través del agente. Meta afirma que ese camino ya ha sido cerrado mediante el hotfix.