
Loom for AWS otorgaba superadministrador a cada solicitud no autenticada — CVE-2026-103956
- OrcaNUEVOOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 por 1M de tokens · 55 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2952Inteligencia
- anthropicAnthropic: Claude Sonnet 5.52026-09-2856Inteligencia
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 por 1M de tokens · 771 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2238Inteligencia
- OpenAIOpenAI: GPT-6 Sol2026-09-2248Inteligencia
- AnthropicAnthropic: Claude Opus 5.52026-09-2258Inteligencia
- xAIGrok 4.72026-09-2146Inteligencia
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 por 1M de tokens · 40 tok/s
- OrcaOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 por 1M de tokens · 2230 tok/s
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-09-1040Inteligencia
- OpenAIOpenAI: GPT-6 Astra2026-09-0453Inteligencia77Código
- GoogleGoogle: Gemini 3.8 Flash2026-09-0241Inteligencia76Código
- AlibabaQwen: Qwen3.8 Max (0902)2026-09-0245Inteligencia76Código
- AnthropicAnthropic: Claude Fable 5.12026-09-0153Inteligencia82Código
- TencentTencent: Hy4 preview2026-08-28$0.83 / $2.50 por 1M de tokens · 57 tok/s
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 por 1M de tokens · 125 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642Inteligencia72Código
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 por 1M de tokens · 205 tok/s
- z-aiZ.ai: GLM 5.32026-08-1845Inteligencia75Código
El 2 de octubre de 2026, AWS publicó el Boletín de Seguridad 2026-124-AWS, en el que divulgaba CVE-2026-103956 en Loom for AWS, la plataforma de código abierto de AWS Labs para crear, implementar y gestionar agentes de IA en Amazon Bedrock AgentCore Runtime. En una implementación en la que no se había configurado ningún proveedor de identidad, la dependencia de autenticación del backend otorgaba una identidad fija de superadministrador a todas las solicitudes entrantes, incluidas las que no llevaban ningún encabezado Authorization. Un cliente remoto capaz de alcanzar el backend podía registrar servidores de herramientas, leer las credenciales de integración almacenadas y reescribir las políticas de roles de IAM asociadas a los roles de agentes gestionados: control administrativo total del plano de control de agentes sin autenticación alguna. NVD puntúa la vulnerabilidad con 10,0, crítica, tanto en CVSS 3.1 como en CVSS 4.0. El crédito por el hallazgo corresponde a Kenneth Cox, en el marco de una divulgación coordinada. El aviso describe lo que la vulnerabilidad permitiría hacer; no describe lo que alguien hizo con ella.
Lo que la dependencia de autenticación estaba haciendo en realidad
El defecto residía en la dependencia de autenticación del backend. Según el aviso de GitHub GHSA-vgmj-998f-r8mp, la ruta de código en la dependencia de autenticación del backend — la get_current_user función en el backend de Loom — devolvía una identidad de administrador codificada de forma rígida, una cuenta de superadministrador en el g-admins-super grupo, siempre que no existiera ningún grupo de usuarios de Amazon Cognito ni ningún proveedor de identidad externo activo. No comprobaba si el llamador había presentado un token. No pasaba a un rechazo. Devolvía la identidad de administrador de todos modos.
El boletín de AWS describe la consecuencia de la misma manera: la falla permitía a cualquier cliente de red obtener plena autoridad administrativa sobre el plano de control del agente. CVE-2026-103956 está mapeado a CWE-306 (autenticación faltante para una función crítica) y CWE-1188 (inicialización predeterminada insegura de un recurso). El vector CVSS 3.1 de NVD es AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — accesible por red, de baja complejidad, sin privilegios, sin interacción del usuario, alcance modificado, impacto total en la confidencialidad, la integridad y la disponibilidad.
El encuadre importante, y la parte que explica por qué un CVSS 10.0 recayó sobre un pequeño proyecto de código abierto, es que un despliegue sin IdP no es algo exótico. Una instalación reciente de Loom que aún no tiene Cognito conectado se encuentra exactamente en ese estado, y también un despliegue cuya configuración de proveedor de identidad nunca se estableció o dejó de resolverse. El aviso trata esto como una condición común y no como una mala configuración que el operador tuviera que propiciar.
A qué podría acceder un cliente no autenticado
• Registros de agentes y servidores de herramientas: el cliente podría registrar o alterar los servidores de herramientas que un agente tiene permitido invocar, lo que en una arquitectura de invocación de herramientas es la diferencia entre un agente que lee un ticket y un agente que ejecuta algo.
• Credenciales de integración almacenadas: la plataforma almacena credenciales para los sistemas externos a los que se conectan sus agentes y servidores de herramientas, y el boletín indica que esas credenciales eran legibles.
• Políticas de rol de IAM en roles de agente gestionados: el aviso describe la reescritura de las políticas de rol de IAM adjuntas a los roles que Loom gestiona para sus agentes, que es el paso que convierte el control de la capa de orquestación en control de lo que los agentes pueden hacer dentro de la cuenta de AWS.
• Todo lo demás que gestiona la plataforma: agentes, memorias, configuración del autorizador y de seguridad, ajustes — y la invocación de cualquier agente que ejecute el despliegue.
Esos cuatro elementos son la propia lista del aviso sobre lo que alcanza el acceso administrativo total, no una reconstrucción. No se afirma que ninguna explotación haya utilizado ninguno de ellos.
Establecido, y no establecido
Confirmado. La vulnerabilidad existía y está documentada en fuentes primarias acordadas: el Boletín de Seguridad 2026-124-AWS de AWS del 2 de octubre de 2026, el aviso de GitHub GHSA-vgmj-998f-r8mp publicado el mismo día, y el registro CVE-2026-103956 de NVD. Las versiones afectadas (anteriores a 1.6.1), las puntuaciones CVSS, los mapeos CWE, la versión de corrección y el crédito son consistentes entre ellas. El registro de archivo de este incidente está clasificado con confianza A, no disputado, y lleva real_harm como falso.
Los propios campos del registro sitúan la divulgación el 2 de octubre de 2026, con precisión de día, y describen una afirmación pública de prueba de concepto como no verificada; ni el boletín ni el aviso contienen evidencia de un ataque. El registro público de NVD para CVE-2026-103956 enumera el catálogo de vulnerabilidades explotadas conocidas de CISA como vacío para este CVE, y el registro de archivo indica real_harm como false. Así pues: una vulnerabilidad que un cliente de red no autenticado podría aprovechar, sin evidencia en las fuentes de que alguien lo haya hecho.

También vale la pena separarlo. El CVSS 10.0 mide lo que la falla permitiría, no lo que hizo. Un 10.0 sin explotación y sin daño registrado es un casi accidente, y así lo archiva el registro.
La solución, y el lapso de dos meses antes de que se le diera nombre
AWS corrigió el problema en Loom 1.6.1, publicado el 4 de agosto de 2026. Esa fecha importa: la publicación se produjo unos dos meses antes del boletín y el número CVE ya existía públicamente. Las notas de la versión v1.6.1 describen el cambio sin nombrar un CVE —la omisión de autenticación ahora requiere una habilitación explícita más un cliente de loopback y, de lo contrario, falla de forma segura con un 401—, por lo que la gravedad de la vulnerabilidad y su designación solo eran visibles para los usuarios de Loom que seguían los rastreadores, no para quien leyera las notas de la versión por sí solas. Esa misma versión añadió un refuerzo contra SSRF para las solicitudes de descubrimiento de OAuth.

Para las implementaciones que ya están expuestas, la guía de AWS previa a la actualización consiste en tener un grupo de usuarios de Amazon Cognito o un proveedor de identidad externo activo configurado por completo antes de que se pueda acceder al backend más allá del loopback, y confirmar que LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV no esté establecido fuera del desarrollo local, y restringir el acceso de red o de grupos de seguridad al backend mientras tanto. El boletín indica explícitamente que la restricción de red reduce la probabilidad de acceso no intencionado, pero no resuelve el problema sin la actualización, y que las bifurcaciones y el código derivado también deben parchearse.
Mismo boletín, diferentes defectos
El resumen del registro señala que 2026-124-AWS no se refiere únicamente a este CVE. Otros dos problemas de Loom se divulgaron el mismo día y se corrigieron en Loom 1.7.0: CVE-2026-103957, un SSRF en el manejo del descubrimiento de OAuth2 que podía enviar secretos de cliente de OAuth2 o el token de acceso de otro usuario a un endpoint controlado por el atacante (CVSS 3.1 6.2, CVSS 4.0 8.2), y CVE-2026-103958, un SSRF en el manejo de conexiones de servidores de herramientas y agentes remotos que podía alcanzar direcciones internas arbitrarias, incluido el endpoint de distribución de credenciales del contenedor, y leer las respuestas (CVSS 3.1 7.6, CVSS 4.0 8.3). Ambos requerían un usuario autenticado que dispusiera del ámbito mcp:write o a2a:write. El boletín también cubre CVE-2026-104019, una inyección de comandos del sistema operativo en el script de validación de inicio de Studio Space que utiliza Amazon SageMaker Unified Studio, con una puntuación de 9.0 crítica según CVSS 3.1, que AWS afirma haber corregido del lado del servidor con un cambio global de saneamiento aplicado en el siguiente reinicio de Space.
Después de la actualización, AWS pide a los operadores que roten los secretos de cliente de OAuth2 para las integraciones de MCP y A2A, que revoquen y reemitan los tokens que estuvieron activos durante la ventana afectada y —si se llegó a las credenciales del rol del contenedor— que roten las credenciales de sesión del rol de IAM y revisen CloudTrail.
Por qué este registro está en el archivo

CVE-2026-103956 se registra como una vulnerabilidad, no como un incidente: encontrada, no necesariamente explotada, INFRA y CRED, GLOBAL, severidad alta, confianza alta. Su valor en el conjunto de registros es como caso límite para toda la categoría de planos de control de agentes. La función de Loom es mantener las identidades, los registros de servidores de herramientas junto con sus credenciales de integración, y las políticas de IAM que deciden a qué pueden acceder los agentes — la capa que conecta una plataforma de agentes con la cuenta de nube en la que reside. La falta de una comprobación en esa capa no degrada a un agente; transfiere el control del entorno. Un registro hermano en el archivo, la divulgación de AgentCorruption del 8 de octubre de 2026 contra Amazon Bedrock AgentCore, describe cómo se alcanza la misma capa por una vía diferente, una cadena SSRF desde un agente expuesto públicamente.
El archivo enumera cada incidente documentado de agente que contiene, cada uno con sus propias fuentes, gravedad, grado de confianza y marca de disputa, junto con este. Este artículo trata sobre un único registro de ese conjunto, y el registro es donde reside la clasificación completa campo por campo.
Este es un registro, investigado y reportado por otros, y aquí se les cita a ellos. La capa propia de Loom —identidades, registros de servidores de herramientas y las políticas de IAM que determinan a qué pueden acceder los agentes— es también la capa a la que llegan las entradas hermanas de el archivo de incidentes de IA, y cada uno de esos registros lleva sus propias fuentes, severidad, grado de confianza e indicador de disputa.
