Servidores MCP sin autenticación: ~40% en los estudios de 2026

Voy a empezar por lo obvio: este artículo no habla de tokens que se escapan. Ya escribí antes sobre cómo un servidor MCP puede inflar tu factura de LLM sin que te enteres. Hoy la incomodidad es distinta. En vez de la billetera, el problema son las llaves de la casa, y muchas casas tienen la puerta simplemente sin cerradura.

MCP (Model Context Protocol) es la forma estándar en la que un cliente como Claude Desktop conecta modelos con herramientas externas. Es cómodo, se instala con un npm install y en cinco minutos ya estás llamando funciones de GitHub o Slack desde el LLM. Si aún no viste cómo funciona el protocolo, hay un recorrido de MCP en 5 minutos que sirve de mapa. La comodidad es real. Lo que sigue también.

Los números de 2026, con fuente

La cifra que más se repite en 2026 no salió de un estudio interno. Salió de investigaciones y escaneos independientes de este año, cada uno midiendo un ángulo distinto. No son números que yo haya medido; cito la fuente de cada uno.

“~40% sin autenticación” significa que, de cada diez servidores, cuatro dejan la puerta sin cerradura. Censys, desde otro ángulo, mapeó 12.520 servicios MCP expuestos a internet — pero esa es la cuenta de exposición, no la tasa de “sin autenticación”. Son dos mediciones distintas; no las mezcles. Cualquier cliente HTTP puede pedirle a un servidor sin autenticación la lista de herramientas y, en muchos casos, ejecutarlas. Los que preferimos no ser noticia deberíamos revisar nuestro mcpServers esta misma semana.

Por qué la superficie de MCP es más grande que la de una API normal

Antes de mirar categorías, conviene entender por qué MCP se rompe distinto. No es que los desarrolladores sean descuidados. Es que MCP suma cuatro propiedades que rara vez conviven en una API tradicional.

Primero, comunicación bidireccional: el servidor MCP puede pedirle cosas al LLM usando sampling, no solo responder. Segundo, multi-tool: en una misma sesión conviven varios servidores MCP a la vez, y ninguno sabe qué hacen los otros. Tercero, control por lenguaje natural: la descripción textual de una herramienta le dice al modelo cómo comportarse, y esa descripción es un vector de ataque en sí misma. Cuarto, permisos altos: MCP suele tener acceso a filesystem, bases de datos y APIs externas. En la industria de seguridad a este combo se le llama el escenario keys to the kingdom. La metáfora es exagerada, pero la mecánica es exacta: comprometer un servidor MCP abre puertas al resto del entorno. Y como la mayoría de las tools por defecto vienen “todo habilitado”, el escenario es más común que la excepción.

OWASP MCP Top 10: las tres categorías que hoy hacen más daño

OWASP publicó su MCP Top 10 en versión beta en 2025. Son diez categorías, pero en la práctica hay tres que concentran los incidentes reales que se están viendo este año.

MCP03 — Tool Poisoning. El atacante mete instrucciones ocultas dentro de la descripción de una tool. La descripción es texto que el modelo lee como parte de su contexto operativo, así que una línea insertada ahí funciona como un prompt privilegiado. Invariant Labs documentó un caso donde un servidor de clima incluía en su descripción instrucciones ocultas para el modelo. El usuario preguntaba por el clima. La conversación salía por la puerta trasera. Nadie audita las descripciones porque, seamos honestos, nadie lee las descripciones.

MCP06 — Prompt Injection vía payloads contextuales. El LLM no distingue entre “esta frase la puso el usuario” y “esta frase venía dentro de un documento que leí”. Basta con que la agenda del correo, una celda oculta de una spreadsheet o un ticket de Jira contenga instrucciones para que el agente las trate como órdenes. Cuando además hay múltiples servidores MCP conectados, la injection puede saltar entre ellos: el input viene por una tool y la acción sale por otra. Es el mismo patrón que en los agentes autónomos donde una web maliciosa engaña al navegador; si te interesa esa vertiente, ya conté cómo terminé poniendo cuatro capas de defensa a un agente de 24 horas.

MCP07 — Autenticación y autorización insuficientes. Aquí vive el famoso ~40%. La especificación MCP declara la autenticación como opcional. “Opcional” es un adjetivo que en producción se traduce como “nadie la va a poner”. La misma medición de 2026 que encontró 40,55% sin autenticación halló además, entre los 119 servidores que sí implementaron OAuth, 325 fallos de configuración — y 9 CVEs salieron de ahí. Cuando no hay autenticación, no es que se rompió el candado: es que no había candado.

Los CVEs recientes, atribuidos como toca

Un escaneo a gran escala, VIPER-MCP, rastreó cerca de 40.000 repositorios de servidores y desenterró 106 zero-days y 67 CVEs. No es un incidente aislado: es el retrato de un ecosistema casi sin defensa. Vale la pena leer bien un par de casos porque los titulares tienden a mezclarlos con “servidor sin autenticación”, y no todos son lo mismo.

CVE-2025-54136 (MCPoison) — CVSS 7.2 (valor asignado por el CNA; el NVD puede registrar otro). Después de que el usuario aprueba un archivo de configuración MCP una vez, un atacante cambia el contenido por un comando malicioso sin que haya un nuevo aviso ni una nueva aprobación. La reportó Check Point contra Cursor y se corrigió en la v1.3. La confianza de “esto ya lo aprobé” quedó indefensa frente al cambio posterior del contenido, y de ahí nace ejecución de código persistente.

Command injection en MCP de nube no oficiales. Trend Micro encontró 1.467 servidores de AWS/Azure MCP no oficiales con command injection de CVSS 9.8. Aquí el input del usuario se convierte en comando de sistema por un fallo de implementación — y cuantas más tools tienes cargadas en una sesión, más maneras hay de que una empuje al modelo hacia otra.

El ataque que apunta a la factura, no a los datos

Hasta 2025 los ataques MCP miraban datos: filtrar tokens, exfiltrar archivos, robar sesiones. En 2026 apareció otra familia que apunta directo a lo que a un CFO le duele.

Una investigación publicada en arXiv documentó el caso: un servidor MCP malicioso, co-registrado junto a tools normales, induce al modelo a entrar en ciclos de razonamiento que parecen razonables paso a paso. Ninguna llamada individual se ve rara. El agregado hace explotar la cuenta: los autores midieron hasta 142,4× más tokens que la ejecución legítima. Es un DoS que en lugar de tirarte el servicio, te sube la factura — por eso el nombre Denial-of-Wallet (DoW).

Es el tipo de ataque que un dashboard de “errores 5xx” nunca va a detectar. Todo respondió 200. Todo tardó lo que tenía que tardar. Solo que costó 142 veces más.

Endurecer hoy: seis acciones concretas

Cerrar el 100% de este espacio es imposible. Salir del grupo del ~40% es cuestión de una tarde. Estas seis acciones son las que aplico primero cuando reviso un mcpServers ajeno, priorizadas por relación esfuerzo/daño evitado.

1. Exige autenticación en cada servidor MCP que expongas. OAuth 2.1, mTLS o al menos API keys con rotación. Si no soporta ninguna, no lo pongas detrás de un endpoint público.
2. Registra logs de las llamadas a tools. Sin telemetría no puedes reconstruir qué hizo el agente después del incidente. Es el mínimo para pasar de “pasó algo” a “pasó esto, en esta tool, con este argumento”.
3. Mínimo privilegio en tools. No habilites el “combo completo” de una integración; activa solo las tools que realmente necesita el agente. Cada tool extra aumenta la probabilidad de que una empuje al modelo hacia otra.
4. Audita las descripciones de tools a ojo. Es tedioso. Es el único MCP03 al que hoy se le puede sacar la vuelta sin herramientas comerciales. Cinco minutos por servidor, una vez al mes.
5. Fija versiones de dependencias. Los ataques de supply chain (typo-squatting de nombres tipo mcp-server-s1ack) son el vector barato favorito. package-lock.json no es un adorno.
6. Pon un humano en el loop para operaciones sensibles. Escritura en producción, transferencias, borrados. Si el agente puede hacerlo solo a las 3am, alguien podría hacerlo por él a las 3am.

Ninguna de las seis pide presupuesto. Todas piden cambiar el reflejo de “lo conecto porque funciona” por “lo conecto después de mirarlo”. Ese es el cambio caro.

Cierre

MCP está entrando en la infraestructura de agentes al ritmo que en su momento entró Kubernetes en la de contenedores. La diferencia es que Kubernetes tuvo diez años para hacer que la autenticación fuera parte del default. MCP, hoy, la trata como opcional, y cerca del 40% del ecosistema le tomó la palabra. Los 106 zero-days y 67 CVEs de VIPER-MCP, los 1.467 servidores con CVSS 9.8 de Trend Micro y el 142,4× en la factura del DoW no son un pronóstico apocalíptico: son mediciones de este año, cada una con su fuente. La buena noticia es que la lista de defensas mínimas cabe en seis puntos y en una tarde.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev