GhostShares: 6.800 conversaciones de Meta Muse expuestas por un título en el subdominio DNS

Compartir una conversación con un asistente de IA parece una operación inocua. Pulsas «compartir», aparece un enlace larguísimo con un identificador aleatorio y se lo mandas a tu compañero. Ese identificador es la puerta de entrada, y si es suficientemente largo el criterio es sencillo: nadie puede adivinarlo. El problema es que, en Muse, el agente de IA de Meta, el identificador dejó de ser el único secreto, porque el título de la conversación acabó viviendo en el subdominio. Y los subdominios se publican en DNS, que es un índice público que cualquiera puede consultar.

Los investigadores de la firma de seguridad Claroc descubrieron más de 6.800 direcciones de conversaciones compartidas de Muse con una sola consulta. En el trabajo, del que se hizo responsable Asaf Aprozper, cofundador y CTO de Claroc, la frase que mejor resume el incidente es: «Si nos hubieran preguntado antes, habríamos supuesto que reunir esto costaría un esfuerzo real. Costó una consulta». Meta suspendió la función de compartir mientras revisa el informe.

Lo interesante no es que un atacante entrara en algo. Nadie entró en nada. El contenido era público porque alguien se lo pidió al asistente, y Muse hizo lo que se le pidió. Lo interesante es que una función diseñada para ser privada se convirtió en rastreable por una decisión de diseño que no aparece en ningún panel de configuración.

«Solo quien tenga el enlace puede abrirlo»

La función de compartir de un asistente de IA funciona así por diseño. Creas una página pública con un identificador largo y aleatorio en la dirección. Quien tenga ese identificador puede abrirla sin registrarse; quien no, no puede. La propia documentación de Meta sobre cómo compartir una conversación de Meta AI lo describe así: el enlace no expira y cualquiera puede reenviarlo. No hay caducidad, ni lista de destinatarios, ni aviso al abrir.

Es un modelo razonable y muy usado. El identificador aleatorio sustituye a un sistema de permisos, y funciona mientras el identificador siga siendo secreto. Es la única medida de protección, y por eso todo depende de que ese valor nunca se escriba en ningún sitio donde alguien lo pueda leer sin intención de leerlo.

La causa raíz está en la dirección, no en el token

Muse construye cada enlace a partir del título de la conversación, un identificador aleatorio y el dominio de contenido. Los ejemplos que da Claroc lo hacen evidente:

home-sale-budget-9f21c8a3.cf.metaaiusercontent.com

q3-revenue-review-7b1e42f0.cf.metaaiusercontent.com

staff-vacation-calendar-5d8b7a.cf.metaaiusercontent.com

El fallo está en dónde va el título. Va en el subdominio, no en la ruta. Esa es la diferencia entre algo que se queda en el servidor web y algo que sale al mundo. Un subdominio es un nombre de dominio: para que alguien abra el enlace, su navegador tiene que resolverlo contra DNS, y esa resolución la ve el sistema. Una ruta no se resuelve, se sirve: permanece en el servidor y no se registra en ningún índice público.

El identificador aleatorio sigue ahí, con su longitud, y sigue siendo inútil. Claroc lo resume con bastante exactitud: un identificador solo funciona como secreto mientras sigue siendo secreto, y un hostname no lo es. No hubo que adivinar nada ni forzar nada. La primera vez que alguien abre el enlace, el nombre completo, identificador incluido, se registra en una base de datos pública. El título que el usuario escribió a mano, con todo lo que revela sobre el contenido, acaba indexado junto a todo lo demás.

DNS pasivo: el índice que se construye solo

El mecanismo que lo hace posible es el DNS pasivo. Los proveedores comerciales de este servicio colocan sensores en resolvers recursivos de todo el mundo: cada vez que alguna máquina del planeta resuelve un nombre, ellos guardan esa resolución con fecha y la mantienen consultable. Nadie rastrea nada, nadie fuerza nada. El índice se llena como efecto secundario del funcionamiento normal de la web.

Una consulta al dominio de contenido de Muse devolvió la lista completa, con los títulos legibles en claro. El resultado fueron más de 6.800 hostnames después de filtrar el ruido que deja cualquier dominio con DNS comodín, y casi todos seguían respondiendo con normalidad: sin cuenta, sin pantalla de acceso. Y el directorio sigue creciendo: el día que Claroc miró por última vez, la capa de compartición había acuñado 27 direcciones nuevas. El DNS pasivo no es el único sitio donde aparecen: urlscan.io, el servicio público de escaneo de URLs, ya guardaba más de 70 escaneos de páginas de Muse, indexados y consultables por cualquiera.

Hay un detalle técnico que merece la pena, porque explica por qué la enumeración fue tan trivial: Muse solo envía el título en su primera respuesta y pinta la conversación con JavaScript. Una petición plana ve una página casi vacía. Bastaba con cargarla en un navegador normal, y todo lo demás ocurrió sin esfuerzo.

Qué había dentro

Claroc abrió solo unos cientos de esas 6.800 páginas y dejó el resto. La mayoría eran inocuas: sitios de pequeños negocios, anuncios, calendarios de eventos, el tipo de contenido que alguien quiere que se vea. La minoría no lo eran. Seis categorías, descritas por los investigadores solo por tipo, sin nombres ni enlaces:

• Notas de un candidato preparándose para una llamada confidencial de executive search con un laboratorio de IA de frontera, con el contacto interno del laboratorio y la hora exacta de la reunión.
• Revisión interna de ingresos de una empresa de marketing nacional, dirigida a su CEO.
• Solicitud de préstamo de un pequeño empresario, con la cantidad solicitada.
• Una lista de tareas que incluía una alerta de fraude bancario, con número de cuenta parcial y datos de la transacción.
• Informe interno de rendimiento de un inversor inmobiliario, con dos direcciones de inmuebles y cifras exactas de rentabilidad, ingresos e hipotecas.
• Calendario anual de vacaciones del personal de un lugar de trabajo, con decenas de empleados y la semana en que cada uno se iba.

El contenido en sí es lo comprometido, pero el riesgo real no es un archivo confidencial: es un hecho privado construido con piezas públicas. La biografía de un candidato se puede montar a partir de LinkedIn. Lo que no es público es la reunión: quién habla con quién, en secreto y cuándo. Una página así convierte datos dispersos en un objetivo y se lo entrega a cualquiera que sepa buscar en DNS. Para un atacante, una lista así no es información: es un atajo listo para fraude, suplantación o ingeniería social.

Por qué una revisión de configuración no lo encuentra

Este es el punto que más incomoda a los equipos de seguridad, y Claroc lo plantea con claridad: una revisión basada en la configuración documentada de una aplicación no detecta este problema. Cada conversación compartida es una petición individual que hace un empleado, una a una, y Muse la ejecuta tal y como está documentado. Lo que hace que una compartición sea fácil de encontrar, cómo se construye el hostname y cómo DNS lo registra, no aparece en ninguno de los controles de compartición. La aprobación de una herramienta es una foto del momento en que alguien la firmó; las comparticiones ocurren después, sin volver a pasar por nadie.

Tampoco ayuda el robots.txt de Muse, que pide a los rastreadores de búsqueda y de IA que no entren en las rutas de compartición. Pero robots.txt gobierna el rastreo, no el acceso: el descubrimiento de Claroc no pasó cerca de ningún motor de búsqueda. Es la confusión clásica entre apartar la puerta de la calle y tapar la ventana.

Qué hacer en tu organización

Ni la forma de compartir ni la construcción de las URL son ajustes que una empresa pueda cambiar desde fuera. Lo que sí se controla es si tu gente usa Muse y qué le pide que comparta. Las recomendaciones de Claroc, trasladadas a la práctica, sirven para cualquier equipo que tenga IA en la sombra dentro de la empresa:

• Sabe ya quién lo está usando. Muse se lanzó hace semanas y no necesita despliegue por parte de un administrador: el personal puede estar creando y compartiendo conversaciones hoy mismo, sin que nadie haya aprobado la herramienta. Trátalo como cualquier otra aplicación de IA en la sombra.
• Explica qué hace un enlace de compartición. Pedirle a un asistente que comparta una conversación la publica como una página que cualquiera con el enlace puede abrir, y en Muse el título se convierte además en un nombre de dominio público. Dilo en la política de uso de IA, junto a lo que se puede pegar en un asistente.
• Vigila cuándo se crean enlaces públicos. Si tienes un producto de seguridad capaz de ver la actividad de SaaS y de IA, apúntalo justo ahí: marca cuando un usuario crea una compartición pública y trata cada enlace de compartición como una salida de datos de la conversación.
• Si no puedes detectarlo, bloquéalo. Niega muse.ai y su dominio de contenido metaaiusercontent.com en el proxy o en el filtro DNS de los dispositivos gestionados. Es un control tosco, pero cierra la exposición mientras montas uno mejor.
• Audítate a ti mismo con el mismo método que usaron ellos. Busca en DNS pasivo y en urlscan los dominios de contenido de las herramientas de IA que usa tu gente, crea una compartición de prueba y mira qué acaba en el hostname y en la URL. Lo que puedas recuperar tú, puede recuperarlo cualquiera con el mismo acceso.

No es la primera vez

El patrón ya tiene historial. En 2025, las conversaciones compartidas de ChatGPT aparecieron en resultados de Google, y OpenAI retiró la opción que las hacía indexables. Semanas después, Google tenía indexadas más de 370.000 conversaciones de Grok. Desde entonces, mantener las páginas de compartición fuera de los buscadores se convirtió en la precaución evidente. Muse la aplica, y aun así su diseño la anula por la puerta de atrás del DNS.

Ese es el patrón que conviene retener: la función de compartir se sigue diseñando pensando en quién recibe el enlace, y no en quién lo encuentra. El enlace se trata como un secreto porque lo entrega la aplicación. Pero la infraestructura que lo rodea convierte cualquier valor que añadas a la URL en un dato público, y esa decisión no suele estar escrita en ninguna parte.

La nota incómoda

Muse no es un chatbot cualquiera. Para funcionar como se vende, necesita acceso a la mayoría de las cuentas del usuario: rellena formularios, reserva citas, hace compras, crea documentos. Zuckerberg afirmó el mes pasado que estaba construido desde cero para la privacidad y la seguridad. Tres semanas después, el experto en seguridad de macOS Patrick Wardle encontró un fallo de día cero que permitía a cualquier otra aplicación instalada en el mismo dispositivo asumir el control completo de la cuenta de Muse; Meta minimizó su gravedad alegando que solo era explotable en un dispositivo ya comprometido. Ahora este otro: dos incidentes de seguridad en el mismo producto en dos meses, con una arquitectura de confianza que exige acceso casi total a la vida digital del usuario.

La pregunta abierta es la de siempre, y ya se ha planteado antes con los agentes: quién audita a quienes construyen herramientas con acceso privilegiado a los datos. La respuesta de Meta, pausar, revisar y considerar cambios en cómo se pueden descubrir estos enlaces, es la correcta y además llega rápido. Pero el problema de fondo no era el enlace. Era que el título de una conversación confidencial acabó siendo un nombre de dominio público desde el primer día, y eso no lo arregla un botón de pausa.