Expuestos por diseño: una auditoría en vivo de 414 servidores MCP expuestos a internet encontró 68 vulnerabilidades

El 31 de julio de 2026 Nicolás Padilla publicó Exposed by Design (arXiv:2608.00150), un preprint de 13 páginas que describe lo que él llama la primera evaluación dinámica de seguridad conductual de los servidores Model Context Protocol accesibles desde internet. Cuatro rondas de medición ese mes confirmaron 640 servidores de producción activos, de los cuales 414 se probaron activamente; las pruebas produjeron 68 vulnerabilidades notificables, todas presentadas a los mantenedores como GitHub Security Advisories. 380 de los 414 — el 91,8% — no tenían autenticación OAuth, y 687 instancias de herramientas anunciaban ejecución de shell sin controles de acceso. Padilla no reporta ninguna evidencia de que algo de esto estuviera siendo explotado: las pruebas se mantuvieron en prueba de concepto, no se obtuvieron credenciales ni se exfiltraron datos. La lista completa de fuentes del registro, la calificación de gravedad y la evaluación de confianza se encuentran en el archivo de incidentes de IA, junto con los demás hallazgos sobre MCP e infraestructura registrados en torno a él.

Lo que realmente hizo la auditoría

El Model Context Protocol es la interfaz que permite que un agente de IA llame a herramientas alojadas en otro lugar: una búsqueda de documentos, una consulta a una base de datos, un ayudante de shell. Un servidor que lo habla por HTTP y es accesible desde internet es, en efecto, una superficie de herramientas a la que cualquiera puede dirigirse. El artículo de Padilla sostiene que la población de esos servidores nunca se ha contado correctamente y que contarlos es lo importante: el descubrimiento es la parte difícil, y cada encuesta anterior examinó una porción diferente.

Su etapa de descubrimiento combinó once fuentes — crt.sh, Hugging Face, GitHub, npm, Smithery, PyPI, Censys, FOFA, Shodan, glama.ai y pulsemcp.com — con el argumento de que ninguna de ellas por sí sola capta la población. La etapa activa utilizó Corvus, un framework que Padilla desarrolló para el estudio: 34 módulos de prueba que cubren 10 clases de vulnerabilidades específicas de MCP, divididos en 13 estáticos y 21 dinámicos. Está publicado en GitHub bajo la organización CobaltoSec y en PyPI como cobaltosec-corvus, y el propio archivo de estadísticas del repositorio registra el mismo recuento de 34 módulos.

Las cuatro ejecuciones se llevaron a cabo el 15, 18, 21 y 24 de julio de 2026. Las ejecuciones anteriores aportaron únicamente números de confirmación; las tres últimas escanearon 3.485, 3.948 y 4.110 candidatos y confirmaron 140, 464 y 296 servidores activos, respectivamente. Al deduplicar 972 observaciones brutas con 332 apariciones repetidas quedaron 640 servidores únicos confirmados, de los cuales 414 —el 64,7 %— aceptaron pruebas dinámicas completas. Padilla considera que 640 es un límite inferior. Censys, una de las fuentes de descubrimiento, había estimado más de 21.000 endpoints relacionados con MCP en todo el mundo en mayo de 2026, y él usa esa cifra como estimación de escala en lugar de como recuento de lo que probó.

Leídos como un embudo, los números son el verdadero argumento del artículo: una pasada amplia y barata encuentra candidatos más rápido de lo que una pasada cuidadosa puede probarlos. Solo 414 de los 640 servidores confirmados se sometieron a prueba por completo, y Padilla no afirma que el subconjunto probado se parezca al resto no probado.

Lo que encontró

El hallazgo principal es la autenticación, o su ausencia. De los 414 servidores probados, 380 (91,8%) no tenían OAuth. El documento señala que la mayoría del resto utilizaba tokens bearer estáticos o claves de API, a menudo predecibles o vacías; un servidor que acepta una cadena fija tampoco está autenticado de forma significativa. Debido a que la auditoría solo probó servidores que eran accesibles públicamente sin credenciales, esta cifra describe por construcción la población expuesta; no es una estimación para los servidores MCP en general.

Los 68 hallazgos reportables se desglosan por clase, y los recuentos de clase se solapan en lugar de particionar el total: 380 deficiencias de autenticación, 52 instancias de aceptación de fuzzing de protocolos, 47 envenenamiento de herramientas, 38 inyección de comandos, 31 omisión de esquema, 29 falsificación de solicitud del lado del servidor, 24 manipulación de URI de recursos, 22 inyección de prompts, 18 exposición de tokens y 14 indicadores de cadena de suministro. Los módulos de denegación de servicio se escribieron pero deliberadamente no se ejecutaron contra servidores de producción, que Padilla excluye por motivos éticos. Los cuatro tipos de vulnerabilidad nombrados en el resumen —inyección SQL, SSRF contra servicios de metadatos en la nube, inyección de plantillas de prompts y recorrido de rutas mediante manipulación del cursor— aparecen cada uno dentro de esas clases.

La cifra de ejecución de shell necesita una advertencia que el artículo no resuelve. En su sección de resultados, se contabilizan 687 instancias de herramientas con ejecución de shell y sin autenticación en el grupo confirmado de 640 servidores. En la discusión, la misma cifra se introduce con las palabras «de los 414 servidores auditados dinámicamente» y luego se hace referencia al «conjunto confirmado más amplio». Los dos planteamientos no concuerdan, y el artículo nunca proporciona un recuento total de herramientas para los servidores probados, por lo que 687 no puede convertirse en un porcentaje.

El churn es el hallazgo que más cambia cómo deben leerse las cifras. De los 464 servidores confirmados el 21 de julio, 193 —el 41,6 %— habían desaparecido cuando la cuarta ejecución comprobó tres días después. Nueve de los 41 servidores que presentaban un hallazgo CRITICAL también habían desaparecido. Padilla interpreta esto como un despliegue sin revisión; también significa que un hallazgo confirmado el lunes puede que no tenga ningún responsable que le aplique un parche para el jueves.

Los tres estudios de caso y qué se puede comprobar

Se documentan en detalle tres hallazgos, cada uno con un identificador de GitHub Security Advisory. Una inyección SQL en lectorium-corpus-mcp (GHSA-m8qh-p8m5-8c48, clasificada como CRÍTICA) se confirmó con la carga útil ' OR 1=1 -- y un diferencial en el tamaño de la respuesta, sin que se leyera o retuviera ningún contenido del documento. Un SSRF en epwforge (GHSA-r9fx-qwmc-rvx3, ALTA) se confirmó por tiempo: 11,9 segundos frente a una dirección interna de metadatos en comparación con una línea base de 0,3 segundos, sin que se almacenara ningún contenido de la respuesta de metadatos. Una inyección de plantilla de prompt en frootai (GHSA-5h8f-r9g8-5w5p, ALTA) completa el conjunto.

Dos de los tres se pueden verificar directamente. El 30 de octubre de 2026, las dos primeras páginas de avisos se resolvieron públicamente en el repositorio de avisos de CobaltoSec, ambas publicadas el 20 de agosto de 2026, ambas aún indicando "Patched versions: None" y sin CVE. La tercera, GHSA-5h8f-r9g8-5w5p, devolvió "no encontrado" en esa dirección. El repositorio de CobaltoSec listaba 46 avisos publicados en la misma fecha, abarcando servidores MCP y herramientas de IA afines; el artículo contabilizó 19 como divulgados públicamente y 49 aún bajo embargo cuando se redactó. Un artefacto de escaneo de frootai con fecha del 28 de julio de 2026 se encuentra en el repositorio Corvus, así que la prueba ocurrió; solo el aviso no es visible.

El proceso de divulgación en sí se describe a grandes rasgos en lugar de detallarse. Los 68 hallazgos se enviaron a los mantenedores mediante GitHub Security Advisories privados bajo un embargo coordinado de 90 días, y cuando el reporte privado no estaba disponible, Padilla presentó en su lugar una incidencia pública en el repositorio. El artículo informa de manera anecdótica que algunos mantenedores aplicaron parches en menos de 24 horas, otros no respondieron durante semanas y algunos repositorios estaban abandonados. No ofrece un recuento de los mantenedores contactados ni una tabla de tasas de respuesta, y afirma que esos datos se informarán por completo en el momento del envío.

Lo que el artículo no establece

Exposed by Design es una preimpresión de un solo autor. arXiv enumera la versión 1, enviada el 31 de julio de 2026, sin referencia de revista y sin declaración de revisión por pares. El archivo califica la confianza del registro como B —documentada, pero de una sola fuente— y esa calificación se mantiene para todo este texto: cada cifra anterior proviene del artículo de Padilla o de artefactos que él publica, no de una medición independiente.

Ninguna redacción independiente parece haber informado sobre el estudio. Existe cobertura —un análisis escrito por IA en forkast.news, publicaciones en LinkedIn y Medium, un blog de seguridad en chino, una explicación en japonés—, pero parafrasea el preprint sin entrevistar al autor, consultar los avisos ni aportar datos. La cobertura derivada no es corroboración.

Padilla expone él mismo los límites, y son inusualmente específicos. Solo se probaron transportes HTTP; los servidores stdio, el caso local habitual, quedan fuera del alcance. El descubrimiento es de mejor esfuerzo, por lo que 640 es un mínimo. Los 226 servidores confirmados que no se probaron por completo se excluyeron por respuestas 403, reinicios de conexión, respuestas JSON-RPC no conformes o simplemente por estar fuera de línea, y el artículo afirma que el sesgo de selección resultante no puede acotarse. La detección se basa en heurísticas —oráculos de temporización, respuestas diferenciales, inspección de esquemas— sin un banco de pruebas etiquetado ni precisión o exhaustividad publicadas para los 34 módulos. La rotación que documenta socava la validez temporal de los hallazgos individuales. Y un único investigador que realiza verificación manual introduce un riesgo de sesgo de confirmación que él nombra y no cuantifica.

¿Qué cambió después?

El resultado práctico hasta ahora es la herramienta y el flujo de avisos. Corvus se puede instalar y está documentada, y el repositorio de avisos de CobaltoSec contenía 46 entradas publicadas el 30 de octubre de 2026, frente a las 19 divulgaciones públicas que el artículo contabilizó a finales de julio. Dos de los propios estudios de caso del artículo todavía no tienen una versión parcheada; para esos servidores, la divulgación ha producido un registro público pero aún no una corrección.

Para los defensores, la parte útil del estudio es su método más que su titular. Una cifra del 91,8 % obtenida solo de servidores que respondieron sin credenciales dice algo limitado y real: la mayor parte de lo expuesto nunca estuvo protegido, y la rotación de tres días sugiere que mucho de ello se puso en marcha para una demo, un prototipo o una prueba y nunca se fortaleció. Lo que el artículo no puede afirmar es si lo mismo se cumple para los servidores MCP de los que realmente dependen las organizaciones, porque esos nunca formaron parte de la muestra.