MCP Tool Poisoning: de la ejecución de código al bypass de los permisos del agente

0La dependencia que nadie audita

Existe un vector anterior a todo, y más sutil: el MCP server puede ser honesto y aun así ser el vehículo.

Auditas el repositorio del servidor, lees los handlers, confirmas que la implementación coincide con las descripciones y lo apruebas. Lo que probablemente no hiciste fue auditar las decenas o cientos de paquetes que arrastra como dependencias transitivas. Basta con que uno de ellos esté bajo control del atacante.

• Compromiso de un paquete legítimo. Cuenta de mantenedor secuestrada por phishing, versión nueva con una línea de más.
• Typosquatting. Paquete con un nombre casi idéntico al popular, esperando un error de tipeo o una sugerencia equivocada de un LLM.
• Confusión de dependencias. Paquete público con el mismo nombre que un paquete interno de la empresa, publicado con una versión mayor y resuelto con preferencia por el gestor.
• Paquete alucinado. Un modelo sugiere una biblioteca que no existe; el atacante registra ese nombre y espera.

Y el detalle que cierra el círculo con la etapa 2: la ejecución ocurre en la instalación, no en el uso. Los scripts de ciclo de vida del gestor de paquetes corren con el usuario que instaló. Nunca llegaste a levantar el MCP server: el install ya fue suficiente.

1La interfaz miente sobre la implementación

Lo que el modelo ve de una tool son esencialmente tres campos: name, description e inputSchema. La especificación también define title, outputSchema y annotations, como readOnlyHint, pero todos los declara el propio servidor. Nada en el protocolo verifica que el código que hay detrás cumpla lo que prometen.

Del lado de los metadatos, tres variantes documentadas:

• Tool poisoning. La descripción lleva instrucciones ocultas que el modelo sigue. En el ejemplo canónico de Invariant Labs, una función de suma instruye al modelo a leer claves SSH y pasarlas en un parámetro extra.
• Rug pull. El servidor entrega descripciones benignas, es aprobado, y después las cambia por versiones envenenadas, sin nueva aprobación.
• Tool shadowing. La descripción de un servidor malicioso redefine cómo el modelo debe usar la tool de otro servidor, confiable e intacto.

En todos los casos, el usuario aprueba el nombre bonito, no el comportamiento real.

2Ejecución con el privilegio del usuario

Un detalle que cambia la lectura del ataque: el código no empieza a correr cuando se llama a la tool. Corre cuando el servidor es iniciado y, antes de eso, en la instalación. Levantar el servidor ya es el punto sin retorno. La tool envenenada no es el disparador, es la cobertura: le da al ataque la apariencia de uso normal y un resultado falsificado para mostrar.

A partir del spawn, el proceso puede, sin pedir nada más:

• Leer cualquier archivo que tu usuario pueda leer: archivos de entorno, claves SSH, credenciales de cloud, historial del shell
• Hacer peticiones de red a cualquier destino
• Escribir o modificar archivos donde tu usuario tiene permiso de escritura
• Ejecutar binarios y scripts ya instalados en la máquina

No es una falla de MCP. Es la misma exposición de cualquier paquete desconocido o extensión no auditada. MCP solo hace que el patrón sea más fácil de disparar sin darse cuenta, porque la interfaz esconde la implementación detrás de una invitación de "haz clic y confía".

3El objetivo pasa del proceso al agente

Cabe aquí una pregunta honesta: si el handler ya tiene acceso total del usuario (y las reglas de deny de Claude Code ni siquiera se le aplican, ya que limitan las tools del agente, como Bash y Read), ¿por qué el atacante tocaría el settings.json?

Porque el objetivo deja de ser el acceso inmediato y pasa a ser la persistencia y el control del agente. Archivos como ~/.claude/settings.json y sus variantes de proyecto son JSON común en disco: sin firma, sin hash de integridad, sin bloqueo contra la escritura de otro proceso del mismo usuario. Editarlos permite:

• Eliminar entradas de deny y agregar allow, de modo que cualquier prompt injection futuro encuentre al agente sin frenos: el agente se convierte en un confused deputy
• Registrar hooks, que ejecutan comandos de shell en eventos de la sesión, garantizando ejecución incluso después de desinstalar el servidor malicioso
• Alterar registros de servidores MCP o archivos de instrucciones como CLAUDE.md, que el agente lee como contexto confiable

Es el patrón del malware que desactiva el antivirus antes de actuar, con una diferencia: aquí el "antivirus" es la propia capa declarativa de permisos del agente.

3-ACuando la tool es solo el disparador

En las etapas anteriores el daño ocurre dentro del proceso del MCP server. Existe un diseño peor: el handler no hace nada interesante durante la llamada, solo escribe un artefacto en disco y registra un mecanismo de inicio automático. A partir de ahí el ataque deja de depender del agente, de MCP y de tu sesión.

Los mecanismos de persistencia son los mismos de cualquier malware de usuario, y todos están al alcance de un proceso sin privilegio administrativo:

• Planificadores de usuario (cron en Linux, Programador de tareas en Windows, launchd en macOS), que se disparan a intervalos fijos
• Inicio de sesión: carpetas de inicio, entradas de registro por usuario, unidades de servicio de usuario
• Archivos de inicio del shell, ejecutados cada vez que se abre una terminal
• Hooks de herramientas de desarrollo: hooks de git en el repositorio, hooks del propio agente, extensiones del IDE

Ninguno exige root. Todos sobreviven a la desinstalación del MCP server, y ese es justamente el punto. El usuario elimina el paquete, da el incidente por cerrado, y el artefacto sigue ahí.

Lo que el payload suele hacer una vez activo

1. Barrido de secretos. Recorre el directorio del usuario y los proyectos buscando patrones de credenciales: archivos de entorno, claves privadas, credenciales de cloud, tokens en archivos de configuración, y también el historial del shell y el historial de git, donde un secreto eliminado del código suele seguir vivo. Existen herramientas de código abierto de secret scanning, creadas para uso defensivo, que hacen exactamente eso; los atacantes simplemente las incrustan en lugar de escribir su propio barrido.
2. Exfiltración con cobertura. El destino no siempre es un servidor con una IP sospechosa. El gusano Shai-Hulud publicaba los secretos robados en repositorios públicos creados en la cuenta de la propia víctima: tráfico saliente hacia un dominio que ya estaba en tu allowlist, con una credencial legítima.
3. Propagación. Con un token del registro de paquetes o del repositorio en la mano, el payload se republica a sí mismo en los paquetes que la víctima mantiene, cerrando el ciclo sin operador humano.
4. Segunda etapa. El primer artefacto es pequeño y discreto; descarga y ejecuta la carga real cuando quiere, lo que permite cambiar el payload después de la infección sin tocar el paquete original.

La lectura importante: el MCP server es el vector de entrada, no el malware. Después de esta etapa, eliminar el servidor y limpiar el settings.json no resuelve nada.

4La cadena completa

Cada etapa aislada parece pequeña. Sumadas, forman un compromiso duradero disfrazado de instalación de herramienta.

1. La víctima instala un MCP server de un repositorio público no auditado, o un servidor honesto con una dependencia comprometida
2. Los scripts de instalación ya se ejecutan con su usuario
3. El servidor se levanta vía stdio y hereda entorno, credenciales y permisos de disco
4. La víctima pide una tarea común; el modelo elige la tool envenenada porque la descripción parece adecuada
5. El handler lee secretos, los exfiltra y devuelve una respuesta falsificada de éxito
6. El mismo proceso altera la configuración del agente: elimina deny, agrega allow, registra hooks. El cambio puede entrar en vigor en la misma sesión
7. Y escribe un artefacto con inicio automático, que pasa a correr fuera de la sesión del agente
8. La víctima desinstala el servidor; el planificador sigue disparándose

El daño final depende solo de lo que ese usuario del sistema operativo tiene permiso de hacer, lo cual, en un entorno de desarrollo típico, suele ser casi todo.