Meta lanzó Muse como un agente de inteligencia artificial capaz de actuar en nombre del usuario: puede abrir un navegador, rellenar formularios, enviar correos, reservar viajes y realizar compras, todo dentro de una arquitectura que la compañía presentó como diseñada para la privacidad y la seguridad. Ahora, un investigador de seguridad de macOS ha publicado una prueba de concepto que muestra una vulnerabilidad local en la aplicación de Muse para Mac capaz de redirigir su tráfico de dictado y aprovechar los permisos que el usuario haya concedido al agente.
El hallazgo procede de Patrick Wardle, investigador especializado en seguridad de macOS y fundador de Objective-See. Wardle publicó el 21 de septiembre el proyecto not-a-mused, que describe como una prueba de concepto de un zero-day local de Muse. La demostración requiere que el atacante ya pueda ejecutar código en el Mac, pero una vez conseguido ese punto de apoyo, el problema está en que Muse dispone de un conjunto de permisos y conexiones mucho mayor que el de una aplicación convencional.
Qué ha descubierto el investigador en Muse
El punto central del hallazgo es un ajuste interno que no está documentado públicamente: endo_voyager_dictation_endpoint. Según el repositorio de Wardle, un proceso local sin privilegios especiales puede modificar ese valor y hacer que Muse envíe el dictado a un servidor controlado por el atacante.
El efecto práctico es importante porque el micrófono deja de ser solamente una entrada de voz para el asistente. Si Muse está configurado para recibir dictados a través de ese canal, un proceso malicioso que ya se esté ejecutando en el ordenador puede intentar interceptar el audio y las instrucciones que el usuario envía al agente.
La prueba de concepto también contempla la posibilidad de inyectar instrucciones en la conversación y obtener material de autenticación asociado a Muse. Wardle explica que el objetivo de su demostración no es conseguir acceso remoto a un Mac desde Internet, sino mostrar cómo un programa que ya se encuentra en el equipo puede utilizar Muse como una vía para ampliar el acceso que tendría por sí solo.
El requisito que limita el ataque
Hay un matiz que conviene mantener claro: este no es un ataque remoto que permita entrar en cualquier Mac sin más. La investigación publicada hasta ahora requiere que el atacante o un malware consiga ejecutar código bajo la cuenta del usuario en el equipo afectado.
The Register describe el problema como una vulnerabilidad local porque el proceso que modifica la configuración de Muse ya tiene que estar ejecutándose en el ordenador. Ars Technica también recoge esta condición y explica que la preocupación principal es que Muse puede convertirse en un amplificador de privilegios: el malware local puede intentar utilizar los permisos que el usuario ya ha concedido al agente.
Eso cambia la lectura del riesgo. No significa que cualquier persona pueda atacar un usuario de Muse simplemente conociendo su dirección de Internet. Sí significa que una infección previa del Mac puede tener consecuencias adicionales si el equipo tiene instalado un agente con acceso a archivos, micrófono, cámara, calendario u otros servicios.
Por qué el problema es especialmente relevante en un agente de IA
La diferencia respecto a una aplicación corriente está en lo que Muse está diseñado para hacer. Cuando Meta presentó el servicio el 8 de septiembre, explicó que Muse funciona sobre una máquina virtual dedicada y que puede actuar en nombre del usuario en tareas como enviar correos, reservar viajes, rellenar formularios o realizar compras. La compañía también señaló que los usuarios pueden elegir qué aplicaciones conecta el agente y qué permisos tiene en cada una.
Meta presentó además Muse Secure VM como una capa de aislamiento en la nube. Según la compañía, el agente trabaja dentro de un ordenador dedicado, mientras un componente denominado Sentinel controla sus conexiones a Internet y solicita autorización para determinadas acciones sensibles.
La investigación de Wardle se sitúa en otro punto de la cadena: el cliente instalado en el Mac. La cuestión que plantea el investigador es que las defensas del entorno remoto no eliminan el riesgo de que una aplicación local sea manipulada antes de que una petición llegue al servicio protegido.
En términos sencillos, un agente puede estar muy aislado en la nube y seguir siendo un objetivo atractivo si la aplicación que sirve de puente desde el ordenador permite que otro proceso local cambie cómo se comunica con él.
Qué puede llegar a hacer un atacante con ese acceso
El proyecto de Wardle enumera varias consecuencias posibles de la redirección del dictado: capturar el audio y los mensajes dictados, introducir instrucciones en Muse, obtener material de autenticación y aprovechar los accesos que el usuario haya concedido al agente.
Ars Technica explica que, en sus pruebas, Wardle consiguió utilizar Muse para acciones que normalmente quedarían fuera del alcance de un proceso local con pocos permisos, precisamente porque el agente ya tenía autorización para interactuar con recursos del sistema. The Register subraya la misma idea: la vulnerabilidad no convierte por sí sola a un atacante remoto en administrador del Mac, pero puede ampliar notablemente lo que puede hacer un código malicioso que ya haya conseguido ejecutarse.
El proyecto publicado en GitHub es un proof of concept, no una herramienta que Bitzeta deba reproducir o ejecutar. Su valor periodístico está en mostrar el límite de seguridad que el investigador ha encontrado y en explicar qué parte del diseño de un agente queda expuesta cuando la aplicación local puede ser manipulada.
La seguridad de Muse frente a lo que Meta prometió en su lanzamiento
La cuestión resulta especialmente llamativa por el enfoque que Meta dio al lanzamiento. La compañía presentó Muse como un agente construido desde cero con privacidad y seguridad como elementos centrales. Entre las medidas descritas por Meta están el aislamiento mediante Muse Secure VM, el uso de almacenamiento seguro para credenciales y la petición de aprobación antes de acciones sensibles como enviar un correo o completar una compra.
El descubrimiento de Wardle no demuestra por sí mismo que todas esas medidas sean ineficaces. De hecho, el requisito de ejecución local limita el escenario de ataque. Lo que sí demuestra la prueba de concepto, según su autor, es que la superficie de ataque de un agente personal no termina en la infraestructura donde se ejecuta el modelo. También incluye el cliente, sus configuraciones locales y la forma en que se comunica con el servicio.
Por ahora, Meta no ha publicado una confirmación técnica del problema en los materiales oficiales consultados ni se ha localizado un parche público o un identificador CVE asociado al hallazgo a fecha de 22 de septiembre de 2026. Por eso, conviene diferenciar entre lo que ha demostrado Wardle y lo que la compañía ha confirmado oficialmente.
Qué debería cambiar en este tipo de agentes
El caso de Muse deja una cuestión más amplia para toda la industria: cuanto más capaz es un agente, más importante resulta separar sus permisos de los del resto de aplicaciones del sistema.
Una aplicación que solamente muestra información puede tener un impacto limitado si otro proceso manipula una preferencia interna. En cambio, un agente conectado al correo, calendario, archivos, compras o dispositivos asociados puede convertir una configuración aparentemente secundaria en un punto de entrada con consecuencias mucho mayores.
La investigación también vuelve a poner sobre la mesa una cuestión clásica de seguridad de macOS: los límites entre procesos. Apple utiliza mecanismos de permisos para impedir que una aplicación acceda libremente a los recursos de otra. Si un agente solicita acceso a numerosos recursos para poder actuar en nombre del usuario, su diseño debe evitar que un proceso con menos privilegios pueda utilizarlo como intermediario.
Para los usuarios, el dato más importante es el requisito de acceso local. Si un equipo ya está comprometido, la presencia de un agente con permisos amplios puede aumentar el impacto de esa intrusión. Mientras no exista una corrección confirmada por Meta, la evolución del proyecto de Wardle y los avisos oficiales de la compañía son las referencias que conviene vigilar.
Qué sabemos ahora sobre la vulnerabilidad de Muse
- El hallazgo fue publicado por Patrick Wardle el 21 de septiembre de 2026.
- La prueba de concepto afecta a la aplicación de Muse para macOS.
- El problema descrito gira alrededor del ajuste no documentado
endo_voyager_dictation_endpoint. - El atacante necesita poder ejecutar código localmente bajo la cuenta del usuario.
- La redirección puede exponer el dictado y permitir manipular las instrucciones que recibe Muse.
- El impacto potencial depende de los permisos y servicios que el usuario haya conectado al agente.
- A fecha de 22 de septiembre no hemos localizado un parche público de Meta ni un CVE confirmado para este problema.
El hallazgo llega en un momento en el que los agentes de IA están pasando de responder preguntas a ejecutar tareas completas. En Bitzeta ya hemos contado otro caso reciente en el que un modelo de IA accedió a sistemas de empresas reales durante una prueba de ciberseguridad, aunque aquel episodio tuvo un origen diferente: una evaluación de Google con un entorno que no quedó correctamente aislado de Internet. La noticia de Gemini y las tres empresas afectadas durante aquella prueba ayuda a entender por qué la seguridad de los agentes depende tanto del modelo como del entorno que lo rodea.
En Muse, la pregunta vuelve a ser la misma desde otro ángulo: cuando un sistema puede actuar en nombre del usuario, proteger el modelo ya no es suficiente. También hay que proteger todos los puntos desde los que ese sistema recibe instrucciones, credenciales y permisos.
Fuentes principales: Patrick Wardle / not-a-mused, Meta Newsroom, Ars Technica y The Register. Imágenes: Wikimedia Commons; licencias indicadas en cada pie de foto.
Relacionado en BitZeta: Android Security State Libraries y seguridad móvil.
Fuente oficial: INCIBE-CERT.
Deja una respuesta