2026-07-31 · INVESTIGACIÓN · El equipo de Offensive Technology

Seguridad en servidores MCP remotos: lo que muestra un censo de 19,321 servidores publicados

La mitad de los servidores del registro oficial de Model Context Protocol son remotos. Extrajimos la población publicada completa el 31 de julio de 2026, 19,321 servidores únicos, y analizamos cómo se distribuye cada uno. 50.0% expone un endpoint remoto, una URL a la que su agente de IA se conecta a través de la red para que el código se ejecute en la máquina de otra persona y usted solo vea los resultados devueltos. La otra mitad, 48.3%, son paquetes locales que se ejecutan en su propia máquina donde puede inspeccionarlos. Esa sola división es la pregunta de seguridad oculta en cada instalación de MCP: ¿está añadiendo una librería que usted controla, o está conectando su agente al servidor de un desconocido? Además de eso, 30.5% de los servidores le piden una credencial antes de ejecutarse, y la mitad remota se resuelve en 7,420 hosts independientes de terceros. Ninguno de estos números menciona un servidor, una empresa o una persona. Son las tasas base de un ecosistema que la mayoría de los equipos están adoptando más rápido de lo que auditan.

Qué es realmente un servidor MCP remoto

El Model Context Protocol es la conexión que permite a un agente de IA llamar a herramientas externas: leer un ticket, consultar una base de datos, abrir una pull request. Un servidor anuncia un conjunto de herramientas, el agente elige una, envía argumentos y lee la respuesta de vuelta en su contexto de trabajo. Hay dos formas en que ese servidor puede conectarse. Un local servidor es un paquete, en npm, PyPI o una imagen OCI, que usted instala y ejecuta por sí mismo; habla con el agente a través de stdio en su propia máquina. Un remoto servidor es una URL. Su agente abre una conexión hacia él, transmite llamadas a herramientas hacia afuera y transmite resultados de vuelta.

La diferencia radica en el límite de confianza. Con un servidor local, el código, las dependencias y las llamadas de red salientes están en hardware que usted controla y puede inspeccionar. Con un servidor remoto, el código reside en la infraestructura del operador. Usted no lo ve, no puede fijar su versión exacta por hash como lo haría con un paquete, y cada argumento que envía su agente, junto con cualquier elemento que el agente haya decidido incluir como contexto para la llamada, llega a ese operador. Los resultados de las herramientas que regresan son entonces aceptados por el agente como si fueran su propio razonamiento. Esa ruta de retorno es precisamente donde residen el tool-poisoning y la inyección indirecta de prompt.

Cómo se distribuyen los 19,321 servidores publicados

Aquí está la población completa, desglosada según la forma en que cada servidor llega a su agente. La proporción remota es lo más relevante, porque es la parte donde el límite de confianza sale de su máquina.

Vale la pena detallar el desglose exacto, porque las mitades redondeadas ocultan un matiz. De los 19,321 servidores, 8,642 (44.7%) son solo remotos, sin un paquete local que pueda ejecutar en su lugar. Otro 1,014 (5.2%) ofrecen ambas opciones un endpoint remoto y un paquete local, para que pueda elegir. 9,323 (48.3%) son solo paquete local, y un residuo 342 (1.8%) no declaró ni paquete ni un endpoint funcional. Por lo tanto, cuando un servidor es remoto, la mayoría de las veces lo es sin alternativa: usarlo implica aceptar el endpoint de un tercero o no usarlo en absoluto.

La solicitud de credenciales: un tercio de los servidores quiere sus claves

Una herramienta que lee sus issues de GitHub o consulta su stack de observabilidad necesita autenticarse en algún lugar, por lo que las solicitudes de credenciales son esperables. Aún así, vale la pena destacar la cifra: el 30.5% de los servidores publicados, 5,888 de ellos, declara al menos una credencial tipo secreto, una variable de entorno o un encabezado de autenticación cuyo nombre contiene un token como KEY, TOKEN, SECRET, PASSWORD, o AUTH. Aproximadamente uno de cada tres servidores exige una credencial activa antes de realizar cualquier acción.

Combine esto con la proporción de servidores remotos y el riesgo se vuelve más evidente. Cuando entrega una credencial a un servidor local, el secreto reside en su entorno y la herramienta lo utiliza desde su máquina. Cuando entrega una credencial a un servidor remoto, se la está enviando al operador o bien está autorizando a dicho operador a actuar con ella en su nombre. En cualquier caso, el operador se convierte en custodio de su clave. Si ese operador es descuidado con los registros o sufre un compromiso, la credencial que usted delimitó para una herramienta pasa a manos de un atacante. El principio de mínimo privilegio no es opcional aquí: un servidor debe recibir un token delimitado exactamente a lo que sus herramientas necesitan y nada más.

Dónde residen realmente los endpoints remotos

La mitad remota no se reduce a un puñado de nubes de confianza. Los 9,656 servidores con un endpoint remoto se distribuyen entre 7,420 hosts distintos. La cola larga es real: el 98.1% de esos hosts aloja exactamente un servidor, lo que representa una gran cantidad de operadores independientes, cada uno como una entidad distinta a la que tendría que auditar. Si sus agentes adoptaran el registro de forma indiscriminada, estarían abriendo conexiones a miles de endpoints diferentes, la mayoría gestionados por alguien de quien nunca ha oído hablar.

En el otro extremo de la distribución se encuentra la concentración. El mayor host de gateway individual concentra el 13.5% de todos los servidores remotos, y los diez hosts con más tráfico representan 18.9% de los endpoints remotos entre todos ellos. Aproximadamente una cuarta parte de los servidores remotos utiliza un host compartido y multi-tenant en lugar de su propio dominio. Esa es la naturaleza de doble filo de cualquier mercado: unos pocos agregadores gestionan una gran parte del tráfico, lo cual es conveniente, pero también significa que un solo operador o una sola caída afecta a una fracción importante del ecosistema. No vamos a citar esos hosts; el objetivo es mostrar la estructura, no la dirección.

La alarma que no fue tal: Unicode oculto

Un ataque conocido en MCP oculta instrucciones para el agente dentro de los campos de texto que publica un servidor, utilizando caracteres invisibles: puntos de código de etiqueta Unicode, ensambladores de ancho cero, controles bidireccionales y secuencias de escape ANSI. El agente los lee, pero un revisor humano no. Escaneamos todos los campos de texto visibles para el modelo en los 19,321 servidores en busca de esas clases de puntos de código. El resultado es un cero absoluto: 0 de 19,321 servidores contenían caracteres no imprimibles o de tipo inyección en los metadatos de su registro.

Es una buena noticia, pero con matices, y los límites importan. El registro publica el nombre, título y descripción de un servidor, pero no las descripciones de las herramientas individuales que expone, que son los campos que se cargan en el contexto del agente en cada llamada y el objetivo más atractivo para un ataque de instrucciones ocultas. Nuestro resultado nulo indica que la capa de metadatos del registro está limpia hoy. No garantiza que las herramientas detrás de esos servidores lo estén, ya que el registro no expone esa superficie para una lectura pasiva. Por tanto, la conclusión honesta es acotada: en la capa que podemos medir sin interactuar con el servidor de nadie, el canal de caracteres invisibles no se está utilizando.

La perspectiva de un atacante sobre este registro

Analice estos números desde la posición de quien decide si un control de seguridad es relevante. Un atacante que quiera ingresar a una organización a través de sus herramientas de IA tiene dos jugadas evidentes, y el censo muestra que ambas son viables a gran escala. La primera es operar un servidor: publicar algo útil, lograr que se instale y, a partir de ese momento, recibir legítimamente cada petición que envía el agente y controlar cada resultado que lee. Dado que la mitad del registro ya es remota, un servidor remoto adicional no levanta sospechas. La segunda es comprometer a un operador que ya cuenta con la confianza de muchos equipos, y la concentración en la parte superior de la distribución de hosts muestra dónde reside ese punto de apoyo.

La cifra de credenciales actúa como multiplicador. En un tercio de los servidores ya se confía un secreto, por lo que un servidor envenenado o intervenido no se limita a interceptar tráfico; puede poseer claves que dan acceso a los sistemas detrás de las herramientas. Esto es la misma ampliación de superficie que describimos en nuestra guía sobre qué pueden ver realmente los atacantes sobre su empresa, trasladada un nivel hacia adentro: la superficie ya no se limita a sus registros DNS públicos y servicios, sino al conjunto de servidores externos con los que sus agentes tienen autorización para comunicarse. Cada uno de ellos representa una dependencia, y las dependencias son el punto de partida de las intrusiones modernas.

Cómo mantener bajo control los servidores MCP remotos

Nada de esto es un argumento en contra de los servidores MCP remotos. Es un argumento para tratarlos como las dependencias de terceros que realmente son. Si ejecuta agentes interactuando con herramientas MCP, esta es la lista recomendada.

• Mantenga una lista de permitidos, no un registro abierto. Decida qué servidores específicos pueden utilizar sus agentes y fíjela. Que la mitad del registro sea remota significa que la mitad depende de un operador en el que decide confiar, de modo que elija de forma deliberada en lugar de instalar al momento de descubrirlo.
• Priorice la opción local cuando existan ambas. Para el 5.2% que ofrece tanto un paquete como un endpoint, el paquete local mantiene el código y su tráfico en su propia máquina. Opte por esta vía cuando la herramienta no necesite verdaderamente ser remota.
• Delimite cada credencial a la herramienta. Con un 30.5% de servidores solicitando un secreto, genere un token limitado exactamente a lo que requieren las herramientas de ese servidor, rótelo y nunca entregue una clave de amplios privilegios a un servidor que no haya auditado.
• Trate la salida de las herramientas como entrada no confiable. Los resultados devueltos por un servidor pueden contener instrucciones dirigidas a su agente. Limite lo que el agente tiene permitido hacer con ellos y no permita que el resultado de una herramienta desencadene acciones con privilegios de manera silenciosa.
• Conozca quién está al otro lado. Un endpoint remoto se resuelve en el host de alguien. Para los servidores de los que depende, conozca al operador y recuerde que la mayoría de los hosts en este registro alojan un único servidor gestionado por una sola entidad.

Metodología, para que un escéptico pueda confiar en las cifras

El conjunto de datos es propio, elaborado a partir de una fuente pública y únicamente en formato agregado. Consultamos la API pública del registro oficial de Model Context Protocol y paginamos todo el catálogo el 31 de julio de 2026, almacenando 62,430 registros de versión. Redujimos esa información a los 19,321 servidores marcados como la versión actual y más reciente, que constituye la población activa deduplicada y el denominador de cada porcentaje mostrado aquí. La modalidad de despliegue se clasificó a partir de los paquetes y endpoints remotos declarados por cada servidor; la cifra de credenciales contabiliza cualquier variable de entorno o encabezado de autenticación cuyo nombre contiene un token tipo secreto; la concentración de hosts se calculó resolviendo el nombre de host de cada endpoint remoto; y el análisis de caracteres ocultos evaluó cada campo de texto frente al bloque de etiquetas Unicode, caracteres de formato bidireccional y ancho cero, secuencias de escape ANSI y otros puntos de código de control y uso privado.

Solo leímos la API pública del propio registro. No nos conectamos a ninguno de los servidores listados, no enviamos peticiones al endpoint de ningún operador ni recopilamos información sobre individuo alguno. Leer un catálogo público es una acción pasiva; interactuar con los hosts incluidos no lo sería, y no lo hicimos.

Lo que esto no demuestra

Una cifra sin sus limitaciones es solo marketing, por lo que aquí detallamos los alcances de estos datos.

• Es un solo registro. El registro oficial es el catálogo central, pero existen servidores que nunca se publican en él, y otros directorios listan los suyos propios. Esto mide la población publicada y localizable, no la totalidad de servidores existentes.
• Declarado, no observado. El despliegue y las credenciales se derivan de lo que cada servidor declara en su entrada del registro. Un servidor podría requerir un secreto no listado o incluir un paquete del que realmente no dispone soporte. Medimos el manifiesto, no una instalación en ejecución.
• Lo remoto es una superficie de riesgo, no un veredicto. Un servidor remoto no es inseguro por el mero hecho de ser remoto. Muchos están bien gestionados por operadores serios. El 50.0% representa la magnitud de la decisión de confianza, no un recuento de actores maliciosos.
• El resultado nulo tiene un alcance delimitado. Cero coincidencias de caracteres ocultos aplica únicamente a los campos a nivel de servidor del registro. Las descripciones por herramienta que se cargan en un agente en cada llamada no se publican para una lectura pasiva, por lo que esto no constituye una certificación de seguridad para las herramientas en sí.
• Es una instantánea. El registro crece a diario. Estas cifras describen la situación al 31 de julio de 2026, no una tendencia, y una nueva extracción el próximo mes alterará estos valores.

Preguntas frecuentes

¿Es seguro usar servidores MCP remotos?

Un servidor MCP remoto es tan seguro como el operador que lo ejecuta, ya que su agente envía peticiones y lee resultados desde el endpoint de dicho operador. En este censo, el 50.0% de los servidores eran remotos y todos utilizaban HTTPS, por lo que el transporte no es la brecha. Lo es la confianza. Fije únicamente los servidores que haya auditado y proporcione a cada uno credenciales con el mínimo privilegio.

¿Cuál es la diferencia entre un servidor MCP local y uno remoto?

Un servidor local se ejecuta como un paquete en su propia máquina, por lo que su código y sus llamadas de red están a su alcance para ser inspeccionados. Un servidor remoto es una URL a la que se conecta su agente, por lo que el código se ejecuta en la infraestructura de un tercero y usted solo ve las respuestas. En el censo, el 48.3% eran solo locales, el 44.7% solo remotos y el 5.2% ofrecían ambas opciones.

¿Cuántos servidores MCP existen?

El registro oficial listaba 19,321 servidores publicados únicos cuando extrajimos la población completa el 31 de julio de 2026, contabilizando solo la versión más reciente de cada uno. Está creciendo rápidamente, por lo que debe tomarse como una instantánea con fecha concreta.

¿Los servidores MCP requieren claves de API o credenciales?

Muchos sí. En el censo, el 30.5% de los servidores declaró al menos una credencial tipo secreto, por lo que aproximadamente uno de cada tres solicita una clave o token antes de funcionar. Esto amplía el radio de impacto en caso de que el servidor o su operador sufran un compromiso.

¿Puede un servidor MCP robar sus datos?

Un servidor malicioso o comprometido puede leer cada petición que le envía su agente y devolver resultados manipulados al contexto del agente, que es la base del funcionamiento del tool-poisoning y la inyección de prompt. No puede ir más allá de las herramientas y credenciales que le otorgue, por lo que el mínimo privilegio y una lista de permitidos auditada constituyen la defensa.

¿El registro de MCP está verificado o auditado?

No. Figurar en el catálogo es un paso de publicación, no una auditoría de seguridad. El registro almacena dónde reside un servidor, no si su operador es confiable. Los servidores remotos se resolvieron en 7,420 hosts, de los cuales el 98.1% alojaba un solo servidor, por lo que la mayor parte de la cadena de suministro está compuesta por operadores que tendría que auditar individualmente.

¿Cuáles son los riesgos de seguridad de los servidores MCP?

Los principales son que un servidor devuelva salidas envenenadas al agente, que un operador remoto vea y registre cada petición, la exposición de credenciales cuando un servidor exige claves y la concentración cuando muchos servidores dependen de un único gateway. En este censo, los trucos complejos como el Unicode oculto no estuvieron presentes en los metadatos del registro (0 de 19,321), por lo que el riesgo inmediato radica en la confianza y el acceso, no en la codificación.

Lecturas relacionadas

• ¿Qué pueden ver realmente los atacantes sobre su empresa? La superficie que esta publicación amplía hacia el interior de sus herramientas de agentes.
• ¿Es suficiente p=none? El mismo método de medición pasiva, aplicado a la autenticación de correo electrónico.
• Autorización primero. Por qué cada medición que publicamos se mantiene estrictamente dentro de la legalidad.