Cuando el agente de IA se conecta al interior: Loom y ToFu muestran que tu servidor es el destino más peligroso

Si ejecutas un sistema de agentes de IA en tu propio servidor Linux, probablemente pienses en el tráfico saliente sobre todo en relación con Internet: adónde envía información el agente y de qué servidor externo descarga código. Un sistema así incluye un orquestador que gestiona los agentes, varios servidores MCP que les proporcionan herramientas y, quizá, una conexión con servicios en la nube. Las conexiones que más daño causan a menudo se dirigen al interior: a 127.0.0.1, a direcciones de la red privada y a endpoints que proporcionan credenciales de acceso a la nube o al contenedor. Las dos publicaciones describen casos en los que el código de infraestructura del orquestador, o las herramientas que ejecuta, abrieron conexiones de este tipo a una dirección elegida por alguien distinto del administrador. En Loom, esto requería un usuario autenticado con los permisos correspondientes.

Analizamos ambas publicaciones juntas porque describen el mismo patrón: un agente de IA convierte el servidor en un proxy que se utiliza contra el propio servidor. La conclusión práctica es que hay que definir una política de destinos en el host para cada proceso de agente por separado. No se debe confiar en que cada componente filtre las URL que recibe.

Qué se ha publicado

Tres vulnerabilidades en Loom. El 2 de octubre de 2026, AWS publicó el boletín de seguridad 2026-124-AWS sobre Loom, una plataforma de código abierto de AWS Labs para orquestar agentes de IA. AWS recomienda actualizar a la versión 1.7.0 y comprobar que los forks y el código derivado también incluyan las correcciones. Según el boletín:

• CVE-2026-103956 (evasión de la autenticación, CWE-306 y CWE-1188): en las versiones anteriores a 1.6.1, si el despliegue no tenía un proveedor de identidad configurado, cualquier cliente de la red podía obtener permisos de administración completos sobre el plano de control de los agentes. Estos permisos permitían registrar servidores de herramientas, leer credenciales almacenadas de las integraciones y reescribir las políticas de IAM asociadas a los roles de los agentes. La vulnerabilidad se corrigió en la versión 1.6.1, publicada el 4 de agosto de 2026.
• CVE-2026-103957 (CWE-918 y CWE-201): en las versiones anteriores a 1.7.0, un usuario autenticado con el permiso mcp:write o a2a:write podía configurar una dirección de descubrimiento de OAuth2. El documento alojado en esa dirección indicaba al servidor que enviara secretos de cliente de OAuth2, o un token de acceso de otro usuario, a un endpoint controlado por un tercero. Según AWS, la versión 1.6.1 bloqueó el acceso a direcciones internas por esta vía, pero no resolvió por completo la filtración de tokens. La corrección completa se incluyó en 1.7.0.
• CVE-2026-103958 (CWE-918): en las versiones anteriores a 1.7.0, un usuario con los mismos permisos podía dirigir las conexiones a servidores de herramientas (MCP) y agentes remotos (A2A) hacia cualquier destino de la red interna y leer las respuestas. Entre los destinos estaba también el endpoint que proporciona credenciales al contenedor.

Un estudio de 273 servidores MCP. El 9 de octubre de 2026, investigadores de Pennsylvania State University, Université Montpellier y Dartmouth College publicaron el artículo sobre ToFu. Crearon una herramienta de fuzzing que genera pruebas de seguridad a partir de las descripciones que las propias herramientas proporcionan al modelo. La ejecutaron sobre 273 servidores MCP de código abierto, que incluían 3,405 herramientas. Según el artículo, encontraron 253 fallos confirmados en 343 herramientas de 118 servidores. Entre los hallazgos figuran 64 casos de recorrido de rutas, 7 de SSRF, 5 de exfiltración de información y 3 de inyección de comandos del sistema. El grupo más numeroso incluía 115 casos de salida devuelta sin aplicar secuencias de escape.

El artículo también describe un ataque que los investigadores llaman Repeat-After-Me: se pide al modelo que repita un texto que parece una llamada a una herramienta. La capa de orquestación interpreta la salida como una llamada real y la ejecuta. Según el artículo, este comportamiento se reprodujo en seis capas de orquestación: LangGraph, MAF, ADK 2.0, AutoGen, Strands y CrewAI. Los investigadores concluyen que un argumento generado por el modelo no debe considerarse una entrada fiable, aunque se ajuste al esquema de la herramienta.

El mismo mecanismo en dos capas

En Loom, el propio código de infraestructura del orquestador abría conexiones a cualquier dirección proporcionada por el usuario. Es el código que gestiona el descubrimiento de OAuth2 y la conexión con servidores de herramientas y agentes remotos. En ToFu, el mismo patrón aparece una capa más abajo, dentro de las herramientas. En el caso analizado en el artículo, una herramienta de captura de páginas web solo comprueba que la entrada sea una URL válida. Según los investigadores, un agente influido por contenido inyectado puede usar esta herramienta para leer archivos del servidor y tomar capturas de servicios que escuchan en loopback y en la red privada. En otro servidor MCP, destinado a WordPress, la herramienta accedía sin restricciones a la URL de un sitio proporcionada por quien hacía la solicitud. Según el artículo, este fallo se encontró en una ejecución con todas las pruebas activadas. El registro de esa ejecución muestra una conexión a 127.0.0.1.

En ambos casos, un componente recibe una dirección del exterior y abre una conexión hacia ella desde el servidor. Desde el punto de vista de la red, la conexión sale del proceso del agente. Por tanto, cualquier servicio que dé por hecho que solo la propia máquina accede a él queda expuesto a este tipo de conexión.

Quién controla la URL

Esta condición limita relativamente el conjunto de posibles atacantes. En las herramientas, ese conjunto es mucho más amplio. El modelo de amenazas de ToFu presupone un atacante capaz de influir en lo que lee el modelo: instrucciones del usuario, contenido recuperado y salidas de otras herramientas. Por eso, los investigadores consideran que cualquier argumento que se ajuste al esquema puede ser hostil. Según el artículo, muchas herramientas confían implícitamente en que el modelo filtre la entrada, aunque esta pueda estar bajo el control de un atacante. En la práctica, quien escribió una página web que leyó el agente puede llegar a decidir la URL a la que accederá una herramienta MCP.

Por qué dirigirse al interior

Desde fuera, un destino interno parece más seguro que uno en Internet. Desde el punto de vista del atacante, ocurre lo contrario. En los destinos internos puede haber servicios cuya seguridad no se ha reforzado porque «solo están en localhost», el plano de control de los propios agentes y endpoints que proporcionan credenciales. En CVE-2026-103958, el atacante no solo llega al endpoint que proporciona credenciales al contenedor, sino que también lee la respuesta. Por eso, si se leyeron las credenciales del rol del contenedor, AWS recomienda sustituir las credenciales de sesión del rol de IAM y revisar en CloudTrail si se han utilizado de forma inesperada. Así, el daño pasa del servidor a la cuenta en la nube.

Las pruebas de SSRF que los investigadores crearon para ToFu también definen los destinos prohibidos de la misma forma: loopback, rangos RFC 1918, direcciones link-local y direcciones de metadatos de la nube. Según la tabla de impacto del artículo, un fallo de SSRF se produce cuando el servidor se conecta a una dirección elegida por el atacante, incluidas las de estos tipos. Una conexión así incumple el requisito de que las solicitudes del servidor solo lleguen a los destinos previstos.

Por qué no basta con corregir cada componente

Hay tres razones. La primera: las correcciones llegan por partes. En Loom, la versión 1.6.1 bloqueó las direcciones internas en la vía de descubrimiento. Aun así, hizo falta otra versión para resolver por completo la filtración de tokens. La segunda: ToFu encontró 7 fallos de SSRF en las herramientas analizadas. Según el artículo, los analizadores que buscan en el código una lista fija de operaciones peligrosas pasan por alto propiedades como «el destino está restringido a una lista de destinos permitidos». No hay un punto concreto del código que se pueda buscar para comprobar esa propiedad. La tercera: según el artículo, solo 273 de los 1,404 repositorios que ofrecen herramientas pudieron ejecutarse en las pruebas. Los demás no se pudieron compilar, no arrancaron o requerían credenciales. Las cifras describen lo que se pudo probar, no el conjunto de repositorios.

Los investigadores recomiendan que cada herramienta aplique por sí misma las restricciones que declara. Es una recomendación adecuada para quienes crean herramientas, pero no basta para el administrador de un servidor que ejecuta diez herramientas de diez autores. El host es donde tienes el control. Una regla aplicada a la dirección a la que el proceso se conecta realmente no depende de cómo esté escrita la URL. ToFu prueba representaciones alternativas de direcciones IP en la entrada, como la notación octal o hexadecimal y las direcciones IPv4 mapeadas en IPv6. Cuando se establece la conexión, la dirección ya se ha interpretado y esas diferencias dejan de importar.

loopback no es una barrera frente a un proceso local

La medida provisional que AWS recomienda para CVE-2026-103956 es asegurarse de que haya un proveedor de identidad configurado antes de que el backend sea accesible más allá de loopback. Vincularlo a loopback protege frente a los clientes de la red, que es precisamente el problema de esta vulnerabilidad. Pero no protege frente a SSRF: un agente que se ejecuta en el mismo host llega a 127.0.0.1 sin dificultad. Por eso hay que abordar ambos lados. Los planos de control deben estar vinculados a loopback, y los procesos de los agentes deben limitarse a los destinos que hayas autorizado expresamente, sin ningún otro acceso al loopback del host.

Medidas prácticas en el servidor

Si ejecutas Loom:

• Actualiza a 1.7.0 y comprueba que tus forks también incluyan las correcciones.
• Hasta que actualices: comprueba que haya un grupo de usuarios de Cognito o un proveedor de identidad externo completamente configurado antes de que el backend sea accesible más allá de loopback. Comprueba también que la variable LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV no esté definida en ningún entorno desplegado que no sea de desarrollo local. Esta es la indicación de AWS. A diferencia de lo publicado en la cobertura de GBHackers, no se limita a producción. Además, restringe mcp:write y a2a:write a administradores de confianza. Según AWS, esta medida reduce el riesgo, pero no lo elimina sin la corrección.
• Después de actualizar: sustituye los secretos de cliente de OAuth2 en las integraciones MCP y A2A. Revoca y vuelve a emitir los tokens que estuvieron activos durante el periodo en que el sistema fue vulnerable. Si se leyeron las credenciales del rol del contenedor, sustituye las credenciales de sesión y revisa CloudTrail.

Para cualquier sistema de agentes:

1. Identifica qué orquestadores, agentes y servidores MCP se ejecutan en el servidor, y cuáles reciben una URL, un nombre de host o una dirección como entrada. Por ejemplo: herramientas de recuperación de páginas y de captura de pantalla, webhooks y mecanismos de descubrimiento.
2. Vincula los planos de control, las interfaces de administración y las bases de datos a 127.0.0.1. Comprueba el estado real, no solo el archivo de configuración.
3. Ejecuta cada agente con su propio usuario, en un espacio de nombres de red independiente o en un contenedor independiente, de modo que su loopback no sea el del host y las reglas del cortafuegos puedan identificar su tráfico.
4. Para estos procesos, bloquea por defecto el loopback del host, las direcciones link-local (169.254.0.0/16 y fe80::/10), los rangos RFC 1918 (10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16) y las direcciones IPv6 privadas (fc00::/7). Permite el acceso solo a los destinos internos que el agente realmente necesite, uno por uno.
5. No te limites a bloquear sin dejar registro: registra cada intento de un proceso de agente de acceder a una dirección de metadatos o a un endpoint que proporcione credenciales. Un intento así es un hallazgo que justifica una revisión.
6. Reduce los permisos del rol de la nube asociado al agente. Si se filtran credenciales, estos permisos determinarán el alcance del daño.
7. Prueba los servidores MCP nuevos en un entorno aislado. Según el artículo, cuatro servidores afectaron al host durante las pruebas: eliminaron archivos fuera del espacio de trabajo, accedieron a una ruta fuera del directorio previsto, cerraron sesiones de terminal que no les pertenecían y lanzaron procesos sin límite. Los investigadores señalan que estos casos son otra razón para ejecutar estas pruebas en un entorno de aislamiento.

Cómo ayuda nuDefend

El comando nudefend workloads muestra las herramientas de IA que se ejecutan en el servidor, incluidas las plataformas de agentes y los servidores MCP, tanto si se ejecutan directamente en el host como si lo hacen en un contenedor. Junto a cada herramienta aparece la información utilizada para identificarla.

El comando nudefend egress review muestra, para cada herramienta, los destinos a los que se ha conectado, el volumen de tráfico hacia cada destino y cuándo se detectó cada uno por primera vez. Los destinos identificados aparecen con su nombre y una descripción de su tipo de actividad. Así, un destino inusual que no esperabas destaca en la lista.

Con esta información puedes definir una política. Primero se supervisa el tráfico, después se autorizan los destinos que la herramienta realmente necesita y se activa la restricción. Una vez activada, la herramienta solo puede conectarse a los destinos autorizados. Cualquier intento de conexión a otro destino se bloquea antes de que el tráfico salga del servidor. nuDefend también limita los nombres que la herramienta puede resolver. Cada consulta bloqueada se muestra junto al nombre de la herramienta.

El comando nudefend expose muestra todos los servicios que escuchan en el servidor y quién puede acceder a ellos, desde el punto de vista del propio servidor. Un servicio vinculado a 127.0.0.1 o a ::1 se marca como local-only. Si un servicio que antes era solo interno pasa a ser accesible desde el exterior, nuDefend detecta el cambio y genera una alerta. Si un servicio está expuesto por error, puedes bloquear su puerto desde el panel de control o la línea de comandos, tras una vista previa que muestra exactamente qué se bloqueará. Encontrarás más detalles en la página sobre el tráfico saliente y en la página sobre la exposición.

En resumen

Las vulnerabilidades de Loom y los hallazgos de ToFu describen el mismo problema en dos capas: un componente del sistema de agentes recibe una dirección de alguien distinto del administrador y abre una conexión hacia ella desde el servidor. A menudo, el destino es el propio servidor, la red privada o un endpoint que proporciona credenciales. Actualiza Loom a 1.7.0 y gestiona las credenciales según las indicaciones de AWS. Además, no esperes a que cada autor de herramientas corrija el tratamiento de las URL. Vincula los planos de control a loopback, separa cada agente a nivel de red y bloquea por defecto el acceso de los procesos de los agentes a destinos internos. Trata cada intento de acceso a una dirección de metadatos como un incidente que requiere revisión.