Los servidores MCP de Markdown que buscaban credenciales en la nube

por

Voy añadiendo herramientas a mis agentes de IA según las necesito. Un servidor MCP para trabajar con documentos, otro para consultar información, otro para conectar algún servicio. Una línea en la configuración, compruebas que funciona y sigues con lo tuyo.

Pero hay una diferencia importante entre instalar una herramienta y saber lo que hace cuando se ejecuta.

El 2 de noviembre, la base pública de paquetes maliciosos de OpenSSF registró cuatro paquetes npm que se presentaban como servidores MCP para trabajar con Markdown. Prometían generar índices, contar palabras y dar formato a tablas. Funciones bastante corrientes, que difícilmente despiertan sospechas.

Los nombres eran casi idénticos:

@ifasn/md-doc-mcp, @ifasn/mdd-doc-mcp, @ifasn/mmd-doc-mcp y @ifasn/mmdd-doc-mcp.

El análisis de Amazon Inspector, recogido en las fichas públicas, muestra que ejecutaban código que tenía muy poco que ver con Markdown.

Qué hacían los paquetes @ifasn al arrancar

Los cuatro consultaban servicios de metadatos de la nube: dos, los de AWS, Google Cloud, Azure y Alibaba Cloud; los otros dos, solo el de Alibaba Cloud.

Estos servicios permiten que una máquina virtual conozca información sobre sí misma. También pueden proporcionar credenciales temporales asociadas al rol que tiene asignado. Son credenciales que una aplicación puede utilizar para acceder a otros recursos de la infraestructura.

Dos de los paquetes intentaban leer esas credenciales de Alibaba Cloud y guardarlas en archivos locales. Otro enviaba a un servidor externo las respuestas obtenidas al consultar los servicios de metadatos. Un cuarto transmitía los códigos de respuesta, información suficiente para identificar características del entorno y averiguar si había determinados roles disponibles.

Las comunicaciones salientes documentadas utilizaban HTTP sin cifrar y tenían como destino la IP 121.199.24.94, directamente o mediante un alias de nip.io.

Había más. Una de las variantes incluía scripts que buscaban archivos especialmente sensibles: claves SSH privadas, ficheros .env, el fichero de contraseñas del sistema (/etc/shadow) y tokens de Kubernetes. Otra descargaba una dependencia desde un servidor HTTP externo, sin una comprobación de integridad que fijara su contenido.

Los servicios de metadatos solo responden dentro de una máquina en la nube: en un portátil, esas consultas no devuelven credenciales. La descarga de esa dependencia, en cambio, ocurre en cualquier ordenador donde se instale el paquete, y npm ejecuta los scripts de instalación que traiga.

Los comentarios del código describían estas operaciones como tareas de sincronización de configuración empresarial o comprobaciones de salud.

Nada de eso era necesario para contar palabras o generar un índice de Markdown.

Conviene distinguir lo que sabemos de lo que no. Las fichas documentan el comportamiento del código y las versiones afectadas. No sabemos cuántas personas instalaron estos paquetes, cuántos llegaron a ejecutarlos ni si hubo víctimas. Tampoco sería correcto afirmar que los cuatro enviaban credenciales robadas al exterior.

Un servidor MCP es un programa, no un documento

Está en cómo incorporamos herramientas a los agentes.

Un servidor MCP local no es un documento que Claude Code, Cursor u otro agente se limita a leer. Es un programa que se ejecuta en tu ordenador o en otro entorno de trabajo.

Dependiendo de cómo esté configurado, ese proceso puede tener acceso a tus archivos, variables de entorno, credenciales y conexiones de red. No necesita que el agente decida buscar una clave: puede hacerlo por su cuenta cuando se inicia.

Y aquí aparece algo que me preocupa especialmente.

Cuando revisamos la configuración de un agente, normalmente vemos el nombre del servidor, el comando que lo arranca y poco más. Podemos saber que hemos conectado una herramienta para Markdown. Eso no nos dice si el código también consulta credenciales de la nube.

El nombre explica para qué se supone que sirve una herramienta. No demuestra lo que hace.

Además, muchos servidores MCP se ejecutan mediante npx o mecanismos similares. Si no se fija una versión concreta, una ejecución posterior puede resolver una versión diferente del paquete. La caché y la configuración influyen en ese comportamiento; no significa que se descargue siempre la última versión en cada arranque.

Pero sí significa que haber revisado una herramienta una vez no garantiza que estemos ejecutando exactamente el mismo código semanas después.

Cómo revisar los servidores MCP de tus agentes

No hace falta esperar a que aparezca otro caso como este para hacer algunas comprobaciones:

  1. Revisa qué servidores MCP tienes configurados. No solo en la configuración global de cada agente, sino también en los proyectos. Un mismo agente puede arrancar herramientas distintas dependiendo del directorio en el que trabaja.
  2. Comprueba cómo se ejecutan. Mira los comandos, el origen de los paquetes y sus versiones. Fijar una versión ayuda a evitar cambios inesperados, aunque no demuestra que el paquete sea fiable.
  3. Busca los paquetes afectados. Comprueba si aparece algún @ifasn/ en las configuraciones o dependencias. Si encuentras uno de los cuatro paquetes identificados, desactívalo y trata la instalación como un posible incidente: revisa qué pudo ejecutar y a qué credenciales tuvo acceso. Si hay riesgo de exposición, revoca o rota las credenciales desde un entorno limpio.
  4. Si trabajas en infraestructura cloud, revisa los permisos del entorno. Comprueba qué roles tiene asignados, si el proceso puede consultar el servicio de metadatos y qué conexiones salientes permite.

Ninguna de estas comprobaciones sustituye una auditoría del código. Pero ayuda a descubrir herramientas que hemos incorporado y de las que ya ni nos acordamos.

Saber qué has conectado a tus agentes

Este caso me interesa porque refleja una situación que reconozco en mi propia forma de trabajar: los agentes acumulan herramientas, permisos y conexiones con mucha más facilidad de la que tenemos para revisarlos.

Es una de las razones por las que empecé a construir RosmarOps. Quería poder ver qué tienen configurado mis agentes, qué pueden leer y modificar y dónde están los límites de esos permisos. RosmarOps hace ese análisis en tu ordenador, y nada sale de tu equipo sin que tú lo apruebes.

No es un detector de malware. Desde la versión 0.7.3 reconoce estos cuatro paquetes cuando un agente los arranca con una versión fijada o cuando están instalados de forma global. Si la orden no fija versión, no puede saber qué código va a ejecutarse, y lo que no se leyó no cuenta como limpio.

El caso deja una pregunta bastante concreta: ¿cuántos programas estamos ejecutando a través de nuestros agentes sin haber comprobado qué hacen realmente?

Fuentes

Análisis de Amazon Inspector, publicados en la base de paquetes maliciosos de OpenSSF/OSV el 2 de noviembre de 2026:

Documentación técnica: npm exec y comportamiento de npx.

Configurar cookies