91.8% de los servidores MCP auditados en internet no tiene autenticación OAuth

El Model Context Protocol se convirtió en muy poco tiempo en la forma estándar de conectar un agente con el mundo: bases de datos, APIs, sistemas de archivos, CRMs. Esa misma facilidad es el problema. Levantar un servidor MCP toma una tarde; publicarlo en una plataforma serverless, cinco minutos más. Lo que casi nadie hace en esa tarde es preguntarse quién más, además del agente, puede llamar a esas herramientas.

El estudio

"Exposed by Design", publicado en arXiv por Nicolás Padilla (CobaltoSec), es una medición a escala de servidores MCP reales accesibles desde internet. Los candidatos se obtuvieron de once fuentes pasivas — logs de certificate transparency, registros de paquetes como npm, PyPI y Smithery, GitHub, HuggingFace y buscadores como Censys, FOFA y Shodan — y se confirmaron con fingerprinting activo del protocolo. Después se corrió Corvus, un framework abierto con 34 módulos (13 estáticos y 21 dinámicos) que cubre nueve de las diez categorías del MCP Security Top 10. Según el autor, el probing se limitó a interacciones normales del protocolo y no se ejecutaron módulos de denegación de servicio. Los resultados:

• 640 servidores únicos confirmados en cuatro corridas entre el 15 y el 24 de julio de 2026; 414 (64.7%) pasaron por auditoría dinámica completa.
• 91.8% de los auditados (380 de 414) no tenía autenticación OAuth.
• 687 instancias de herramientas exponen ejecución de shell sin controles de acceso.
• 68 vulnerabilidades reportables, registradas como GitHub Security Advisories: 19 ya públicas y 49 bajo embargo de divulgación coordinada a 90 días.
• Por categoría: tool poisoning en 47 servidores, inyección de comandos en 38 y SSRF en 29 (las tres críticas); manipulación de URIs de recursos en 24, prompt injection en 22 y exposición de tokens en 18 (altas).
• En una ventana de 72 horas, 41.6% de los servidores confirmados (193 de 464) desapareció; de 41 servidores con hallazgos críticos, 9 ya no estaban en la siguiente corrida.

Los casos son bugs clásicos con interfaz nueva

Lo más revelador del paper no es ninguna técnica exótica. Es que los casos documentados son vulnerabilidades web de hace veinte años, expuestas ahora a través de un agente:

• Inyección SQL. Una herramienta de búsqueda de documentos pasaba la consulta sin sanitizar a SQLite; el payload ' OR 1=1 -- devolvía respuestas sustancialmente más grandes.
• SSRF hacia metadatos de nube. Una herramienta fetch_url sin validación de dominio aceptaba peticiones al endpoint de metadatos de AWS. La confirmación fue por tiempo: 11.9 segundos de respuesta contra 0.3 de línea base.
• Inyección en la plantilla del prompt. Un servidor construía el system prompt concatenando input del usuario; la secuencia \n---\nNew system instructions: aparecía literal en las respuestas del modelo.

El patrón es el mismo en los tres: se trató el input que llega por MCP como si viniera de alguien de confianza. Y en MCP hay dos fuentes de input no confiable que no existían en una API tradicional: los argumentos que genera el modelo — que pueden estar influidos por cualquier documento, correo o página que el agente leyó — y las descripciones de herramientas que el cliente le inyecta al modelo, que es exactamente donde vive el tool poisoning.

El dato del churn importa más de lo que parece

Que 41.6% de los servidores desaparezca en tres días dice mucho sobre el ecosistema: buena parte de lo que está expuesto son experimentos, demos y despliegues de fin de semana. Eso tiene dos consecuencias prácticas. La primera: un servidor MCP de terceros que funciona hoy puede no existir — o haber cambiado de dueño o de código — la semana que entra. La segunda: si tu equipo levantó un servidor de prueba "solo para ver si funcionaba", es probable que siga ahí, sin autenticación, con las credenciales que le pusiste ese día.

Cómo lo abordamos en SmartDevs

Construimos agentes que se conectan a CRMs, WhatsApp y bases de datos de clientes, así que MCP y protocolos similares son parte de nuestro día a día. Las reglas que aplicamos parten de una premisa: un servidor MCP es una API pública con un cliente impredecible, y se diseña como tal.

• Local por defecto, remoto solo con autenticación. Si el agente y la herramienta viven en la misma máquina, usamos transporte stdio. Si el servidor tiene que estar en HTTP, lleva OAuth 2.1 o un mecanismo equivalente desde el primer deploy — la recomendación principal del paper es justamente que los SDKs lo hagan obligatorio, y no esperamos a que eso pase.
• Nada de shell genérico. Una herramienta run_command es acceso remoto con pasos extra. Exponemos operaciones acotadas (crear_lead, consultar_pedido) con esquemas estrictos, no un intérprete.
• Los argumentos del modelo son input no confiable. Consultas parametrizadas siempre, validación de esquema en el servidor y allowlist de dominios en cualquier herramienta que haga peticiones salientes, con las IPs de metadatos de nube bloqueadas a nivel de red.
• Los servidores de terceros se revisan como dependencias. Leemos las descripciones de herramientas antes de conectarlas, fijamos versiones y no aceptamos servidores remotos que no controlamos para flujos con datos de clientes.
• Aprobación humana para lo irreversible. Enviar mensajes a clientes, borrar registros o mover dinero requiere confirmación explícita, y cada llamada a herramienta queda en un log auditable.
• Inventario y apagado. Todo servidor expuesto tiene dueño y fecha de revisión. Los de prueba se apagan el mismo día.

Nada de esto es nuevo: es seguridad de APIs aplicada a una interfaz nueva. Lo nuevo es la velocidad con la que se publica sin ella. Si tu empresa ya tiene servidores MCP corriendo, la pregunta para esta semana es sencilla: ¿cuántos están accesibles desde internet, cuántos piden autenticación, y cuál de ellos puede ejecutar algo más que lo que su nombre promete?