Se han detectado 36.769 servicios de IA expuestos en Internet público

La accesibilidad pública abarca toda la cadena de suministro de la IA

Un estudio publicado el 11 de septiembre identificó 36.769 endpoints de IA accesibles públicamente, desde servidores de modelos locales hasta plataformas de automatización y consolas de almacenes vectoriales.

Los investigadores de Mysterium VPN encontraron estos sistemas mediante consultas al índice de análisis de Internet de Netlas y la comparación de huellas específicas de cada servicio. Solo el 2,02 % de los endpoints identificados devolvió una respuesta HTTP 401 o 403, códigos de estado utilizados como evidencia de una barrera de autenticación.

Eso no significa que todos los demás servicios permitieran un acceso sin restricciones. Las páginas de inicio de sesión pueden devolver HTTP 200, mientras que la autenticación puede aplicarse en otra parte de la aplicación. La cifra muestra, en cambio, que la mayoría de las implementaciones carecía de un desafío detectable en la capa de red del endpoint analizado.

La investigación midió la exposición observable, no una intrusión con éxito. Los investigadores no recuperaron documentos, inspeccionaron historiales de chats, leyeron credenciales, ejecutaron modelos, explotaron vulnerabilidades ni publicaron nombres de host o direcciones IP.

El total también es un límite inferior. Los índices de análisis de Internet no cubren todos los puertos o hosts, y las huellas estrictas excluyen los sistemas que no pueden atribuirse con confianza a un producto concreto.

Aun así, la distribución muestra cómo la infraestructura de IA autogestionada puede exponer varios activos distintos: capacidad de GPU, credenciales de flujos de trabajo, conexiones con sistemas empresariales y los datos privados utilizados para la generación aumentada mediante recuperación.

Los servidores de modelos dominan la población expuesta

Open WebUI fue el grupo de productos más numeroso del conjunto de datos, con 18.529 instancias accesibles. Solo una devolvió un desafío de autenticación HTTP.

Los investigadores también identificaron:

• 4.880 endpoints de vLLM, de los cuales tres devolvieron un desafío de autenticación;
• 150 endpoints de LocalAI, ninguno de los cuales devolvió un desafío;
• 69 endpoints de llama.cpp, ninguno de los cuales devolvió un desafío.

Estas cifras no permiten establecer que todas las instalaciones pudieran utilizarse de forma anónima. Una interfaz de inicio de sesión de Open WebUI, por ejemplo, puede responder con HTTP 200 y seguir exigiendo credenciales antes de mostrar conversaciones o funciones de los modelos.

Ollama proporcionó evidencias más sólidas porque su endpoint raíz muestra el texto reconocible Ollama is running sin solicitar autenticación. Mysterium encontró 6.935 hosts con esa huella, incluidos 6.046 que respondieron explícitamente con HTTP 200.

Una API de Ollama expuesta puede revelar los modelos instalados y permitir que un usuario externo envíe solicitudes de inferencia utilizando el hardware del operador. En consecuencia, los atacantes pueden consumir tiempo de GPU y electricidad sin comprometer el host en el sentido convencional.

Este abuso de recursos se describe habitualmente como LLMjacking. Puede generar costes, degradar el servicio para los usuarios legítimos y vincular la infraestructura del operador con contenido generado por un tercero desconocido.

Un estudio independiente de SentinelOne y Censys, publicado en enero, contabilizó aproximadamente 175.000 hosts de Ollama expuestos en 130 países. Casi la mitad admitía funciones de llamada a herramientas capaces de ejecutar código, invocar API o comunicarse con sistemas externos. Las diferencias en la cobertura del análisis y en los requisitos de las huellas explican por qué ese total fue considerablemente mayor.

Mysterium observó además 22.024 respuestas en el puerto predeterminado de Ollama, 11434. Estos sistemas se excluyeron del recuento principal porque un puerto por sí solo no demuestra qué aplicación está escuchando. De esas respuestas, 4.136, es decir, el 18,8 %, se originaron en Estados Unidos.

Los investigadores intentaron elaborar un desglose más amplio por países, pero lo descartaron después de que los límites de frecuencia hicieran que los resultados fueran poco fiables para varios países importantes.

Las plataformas de agentes pueden exponer algo más que capacidad de cómputo

El estudio encontró 5.223 plataformas de creación de agentes y flujos de trabajo accesibles públicamente. Entre los productos identificados estaban Flowise, n8n, ComfyUI, Dify, RAGFlow, Langflow y Open WebUI Pipelines.

Estas aplicaciones pueden tener un impacto de seguridad mayor que un servidor de inferencia aislado. Su finalidad es conectar modelos con datos y acciones, a menudo almacenando o haciendo referencia a claves de API de OpenAI, credenciales de bases de datos, tokens de Slack, contraseñas de CRM y secretos de webhooks.

Una plataforma de flujos de trabajo también puede tener permisos para consultar bases de datos de producción, actualizar registros de clientes, acceder a repositorios de código fuente, enviar mensajes o activar otras automatizaciones. Por tanto, la exposición acerca tanto los secretos como las rutas de ejecución autorizadas a un atacante.

Mysterium identificó 1.341 instancias accesibles de Flowise. Ninguna devolvió un desafío de autenticación 401 o 403, aunque esta medición por sí sola no demuestra la ausencia de controles de inicio de sesión en la capa de aplicación.

Flowise también presenta un riesgo de software independiente. CVE-2026-40933 es una vulnerabilidad crítica del adaptador MCP mediante la que un atacante autenticado puede ejecutar comandos arbitrarios. Tiene una puntuación CVSS de 9,9 y el vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

El problema se corrigió en Flowise 3.1.0. Los administradores deberían actualizar a esa versión o a una posterior.

La exposición a Internet no demuestra que ninguno de los sistemas Flowise detectados ejecute una versión vulnerable, y la vulnerabilidad sigue requiriendo acceso autenticado. Sin embargo, una implementación accesible públicamente ofrece a los atacantes más oportunidades para obtener o reutilizar credenciales y, posteriormente, dirigirse a la ruta de ejecución de comandos.

Los tokens filtrados hacen innecesaria la explotación

Los riesgos relacionados con n8n ilustran por qué los equipos de defensa no pueden centrarse exclusivamente en los fallos de software.

En un análisis publicado en agosto, los investigadores de GitGuardian examinaron tokens de API de n8n expuestos en commits públicos de GitHub. Identificaron 4.576 tokens únicos asociados a 1.255 nombres de host.

De esos hosts, 896 eran accesibles durante las pruebas. Al menos un token filtrado funcionaba contra 321 instancias.

En estos casos, el atacante no necesita una vulnerabilidad. Un token válido puede proporcionar acceso directo a los flujos de trabajo y sus integraciones, según sus privilegios y la configuración de la instancia afectada.

Esto convierte las implementaciones de n8n y Flowise conectadas a entornos de producción en almacenes de credenciales de alto valor. Un token filtrado a través del código fuente puede convertirse en el punto de entrada, mientras que un plano de control accesible públicamente proporciona al atacante un lugar donde utilizarlo.

Los equipos de defensa deberían revisar los repositorios y los historiales de commits, no solo la versión actual de un proyecto. Eliminar un secreto de la revisión más reciente no invalida las copias conservadas en commits anteriores, forks, registros o cachés. Toda credencial que pueda haberse expuesto debe rotarse.

Los almacenes vectoriales crean un riesgo independiente de exposición de datos

Mysterium contabilizó 920 endpoints de almacenes vectoriales accesibles, casi todos ellos con consolas de administración Attu para Milvus. Esta categoría es especialmente incompleta porque la fuente de análisis no cubría los puertos nativos utilizados por las bases de datos Qdrant y Milvus.

Por tanto, una base de datos vectorial puede seguir siendo accesible públicamente sin aparecer en el total.

Estos sistemas almacenan embeddings y contenido asociado utilizados por las aplicaciones de IA para recuperar información relevante. Según la implementación, ese material puede incluir documentos internos, tickets de soporte, registros de clientes, instrucciones operativas o entradas privadas de bases de conocimiento.

Una consola de administración expuesta y una interfaz de base de datos nativa expuesta también representan problemas de detección diferentes. Los equipos de seguridad que analicen únicamente los puertos web convencionales pueden encontrar Attu y pasar por alto la base de datos subyacente, o viceversa.

El estudio no inspeccionó colecciones ni recuperó registros, por lo que no establece que se pudiera acceder a los datos desde ninguno de los 920 endpoints. Sí demuestra que las superficies de administración eran visibles desde Internet público.

Los equipos de defensa deben reducir la exposición antes de investigar un compromiso

Las organizaciones deberían empezar por elaborar un inventario de los servidores de modelos, las plataformas de agentes, los motores de flujos de trabajo, las bases de datos vectoriales y las consolas de administración relacionadas. Los activos en la nube y los experimentos temporales de IA requieren especial atención, ya que los servicios pueden quedar vinculados a 0.0.0.0 después de las pruebas.

Cuando no sea necesaria la conectividad pública, los servicios deberían escuchar únicamente en localhost o en interfaces de red privadas. Los sistemas que requieran acceso remoto necesitan autenticación combinada con controles perimetrales, segmentación y restricciones sobre las redes de origen permitidas.

Las acciones prioritarias incluyen:

• Actualizar Flowise a la versión 3.1.0 o posterior.
• Buscar claves de API, tokens de n8n, contraseñas de bases de datos, secretos de webhooks y otras credenciales en los repositorios de código y los historiales de commits.
• Rotar los secretos que puedan haber pasado por flujos de trabajo expuestos o repositorios públicos.
• Restringir las llamadas a herramientas, la ejecución de código, el acceso a API y las integraciones externas que no sean necesarios.
• Proteger las consolas Attu y analizar por separado las interfaces nativas de Milvus y Qdrant.
• Supervisar solicitudes de inferencia inesperadas, el uso de GPU, los cambios en los flujos de trabajo, el consumo de tokens y la actividad en los sistemas conectados.
• Utilizar huellas de productos en servicios de análisis de Internet para localizar activos de la organización visibles desde el exterior de la red.

El estudio no confirmó ningún compromiso. Su conclusión práctica es más limitada, pero sigue siendo importante: decenas de miles de componentes de IA reconocibles son accesibles desde Internet y muchos no muestran ninguna barrera de acceso detectable antes de llegar a la propia aplicación.