Cómo unas preferencias sincronizadas pueden secuestrar las herramientas locales de Claude Desktop
Pentera demostró que un atacante con acceso a la cuenta puede ocultar instrucciones en las Preferencias personales sincronizadas de Claude Desktop para forzar a sus herramientas locales a ejecutar comandos.
¿Qué es esto?
En una investigación publicada a comienzos de julio de 2026 —recogida por The Register el 1 de julio de 2026 y detallada por Pentera Labs bajo el nombre AI Double Agent— un equipo de red team demostró que la configuración sincronizada de un asistente de IA de escritorio muy extendido puede convertirse en un canal persistente de inyección de prompts. El objetivo es el campo Preferencias personales del asistente: un prompt configurable por el usuario que guarda el tono, los flujos de trabajo y pautas de comportamiento, y que se sincroniza automáticamente en todos los dispositivos y sesiones asociados a la cuenta, incluida la aplicación de escritorio.
No se trata de un fallo de corrupción de memoria ni de una vulnerabilidad remota no autenticada. Es un problema de frontera de confianza: un elemento de configuración controlado por la cuenta, que el asistente trata como instrucciones, es también un lugar donde un atacante puede escribir en cuanto controla la cuenta. Los investigadores lo notificaron al proveedor en noviembre de 2025. Este lo reconoció pero se negó a clasificarlo como vulnerabilidad de seguridad, argumentando que las preferencias, skills y conectores son funciones diseñadas para permitir que el asistente actúe, por lo que no se asignó ningún CVE. Ese desacuerdo es en sí mismo lo interesante, y por eso tratamos este caso como una lección defensiva y no como un defecto que parchear.
Cómo funciona
La cadena tiene tres etapas conceptuales, y ninguna requiere entrega de malware ni un correo de phishing enviado a la víctima.
Acceso a la cuenta -> el atacante alcanza la cuenta del asistente de la victima
Payload almacenado -> instrucciones escritas en las Preferencias personales sincronizadas
Sync + disparo -> la app de escritorio las carga y dirige las herramientas locales
En el escenario demostrado, el acceso inicial provino de un servicio de terceros que agregaba las bandejas de entrada de muchos usuarios; una autenticación débil en ese punto permitió a los investigadores saltar a las cuentas asociadas mediante enlaces mágicos y restablecimientos de contraseña. Con la cuenta en su poder, colocaron un bloque de instrucciones codificado en las Preferencias personales. Escrito como una cadena opaca en lugar de comandos en texto claro, pasa fácilmente desapercibido en una revisión rápida: la idea es camuflarse en un campo que los usuarios rara vez auditan.
Como el campo se sincroniza, la próxima vez que la víctima abre la aplicación de escritorio el contenido inyectado se carga en silencio como parte de las pautas permanentes del asistente. A partir de ahí, la lógica del payload es condicional. Si ya hay instalada una extensión capaz de ejecutar comandos —los artículos citan una herramienta local de ejecución de comandos—, se puede dirigir al asistente para que la invoque en segundo plano mientras sigue respondiendo a las preguntas visibles del usuario, creando un bucle en el que cada interacción puede recuperar y ejecutar instrucciones actualizadas desde la infraestructura del atacante. Si no existe tal herramienta, el payload cambia a la ingeniería social: hace que el asistente muestre un error realista, ajustado al flujo de trabajo, que empuja al usuario a instalar una extensión concreta «para resolver el problema». El asistente, en quien el usuario confía, se convierte en la capa de phishing.
Deliberadamente no publicamos ni el payload ni su codificación. Lo que importa aquí es el mecanismo: una configuración almacenada y sincronizada se trata como instrucciones de confianza, y las herramientas conectadas heredan esa confianza.
Por qué importa
Es una instancia concreta de la «tríada letal»: contenido no confiable, un agente con herramientas y la capacidad de alcanzar el exterior. La novedad está en dónde reside el contenido no confiable. La mayoría de la cobertura sobre inyección de prompts se centra en contenido cargado en tiempo de ejecución —una página web, un documento, el resultado de una herramienta—. Aquí la instrucción maliciosa queda aparcada en la propia configuración de la cuenta del usuario y la entrega el mecanismo de sincronización del proveedor, lo que la hace persistente y portátil entre dispositivos.
El radio de impacto depende de la víctima. En una máquina de desarrollo o DevOps, la ejecución de comandos puede significar la obtención de claves SSH, credenciales cloud, kubeconfigs y tokens de CI/CD, y una vía de movimiento lateral hacia producción. En un equipo no técnico, esa misma confianza puede desviarse hacia el secuestro de sesión, la extracción de credenciales del navegador y la suplantación en herramientas colaborativas. Y la postura del proveedor —que se trata de una función esperada— significa que los defensores no pueden esperar un parche para cerrar esta puerta. Si su modelo de amenazas incluye el compromiso de cuentas, la configuración sincronizada del asistente ya forma parte de su superficie de ataque.
Defensas
Proteja primero la cuenta. Toda la cadena empieza cuando un tercero alcanza la cuenta del asistente: la autenticación multifactor, el escrutinio cuidadoso de los agregadores de bandejas de entrada de terceros y de las autorizaciones OAuth, y la vigilancia de señales de toma de control de la cuenta son los controles de mayor impacto.
Trate la configuración sincronizada como un estado no confiable y relevante para la seguridad. Las Preferencias personales, la memoria, los skills y las definiciones de conectores deben revisarse periódicamente y tras cualquier sospecha de compromiso; un bloque codificado opaco en un campo de preferencias es una señal de alarma, no una rareza.
Limite lo que las herramientas pueden hacer. Aplique el mínimo privilegio a las extensiones capaces de ejecutar comandos: instale herramientas de ejecución de código local solo cuando sea realmente necesario, y aíslelas. Exija aprobación humana explícita para cada acción de herramienta en lugar de permitir la ejecución silenciosa en segundo plano, de modo que una instrucción envenenada no pueda dirigir el shell sin ser vista.
Asuma que el asistente puede convertirse en una superficie de phishing. Un asistente de confianza que recomienda instalar una extensión concreta es ahora un vector: verifique cualquier solicitud de este tipo por un canal independiente antes de actuar.
Añada defensa en profundidad alrededor del endpoint. Restrinja el tráfico saliente de los equipos que ejecutan asistentes con herramientas, mantenga un EDR activo y practique una buena higiene de secretos: tokens de corta duración y ninguna clave SSH o credencial cloud de larga duración almacenada en texto claro en los directorios personales.
Estado
| Elemento | Detalle |
|---|---|
| Divulgación | Notificado al proveedor en noviembre de 2025; artículos públicos a comienzos de julio de 2026 (The Register, 1 jul. 2026) |
| Postura del proveedor | Preferencias, skills y conectores MCP considerados funciones diseñadas para ejecutar código; clasificado como comportamiento esperado, sin CVE asignado; mejoras anunciadas como previstas |
| Requisito previo | Requiere acceso previo a la cuenta; no es una vulnerabilidad remota no autenticada |
| Naturaleza | Problema de frontera de confianza / inyección de prompt almacenada que permite la ejecución de herramientas locales y la persistencia vía configuración sincronizada |
| Estado del parche | No se espera parche por diseño: la mitigación pasa por la seguridad de la cuenta, herramientas con mínimo privilegio y aprobación humana |