Amazon Bedrock AgentCore: fallos que exponen credenciales AWS

Entre finales de septiembre y principios de octubre de 2026, tres investigaciones mostraron cómo los agentes creados con Amazon Bedrock AgentCore, el servicio de AWS para ejecutar agentes de inteligencia artificial, podían entregar a un atacante las credenciales AWS de su rol de ejecución. El hilo común no es un único fallo, sino la combinación de tres elementos: un agente que puede ejecutar comandos o generar tráfico, credenciales accesibles desde el entorno en el que se ejecuta y permisos más amplios de lo necesario.

Qué ha pasado

• Dos CVE en el SDK de Python (BeyondTrust). Según Infosecurity Magazine, que recoge la investigación publicada por BeyondTrust el 28 de septiembre, el helper del Code Interpreter que instala paquetes de Python convertía un nombre de paquete manipulado en un comando de shell ejecutado dentro del sandbox. Desde ahí, los investigadores leyeron las credenciales temporales del rol de ejecución.
• «AgentCorruption» (Zenity Labs). Según CSO Online, que recibió el informe por adelantado, los investigadores simplemente pidieron a un agente sus credenciales y las obtuvieron. Dark Reading describe el fallo, ya corregido, como una forma de poner en riesgo todo el entorno AWS de una organización a partir de un solo chatbot.
• AgentCore Harness (Unit 42 de Palo Alto Networks). El 18 de septiembre, Unit 42 informó de que, con la configuración predeterminada, la herramienta de shell integrada, activa por defecto y ejecutada como root, alcanza la memoria en la que las credenciales gestionadas por AgentCore Identity se resuelven en texto claro: con una inyección de prompt, un atacante puede hacer que el agente las exfiltre.

Detalles técnicos

CVE-2026-12530 afecta al SDK de Python de AgentCore desde la versión 1.1.3 hasta la 1.6.0: una lista incompleta de caracteres prohibidos permitía eludir el control del nombre del paquete. AWS la corrigió en la 1.6.1 con una regla de validación más estricta, pero BeyondTrust también la eludió: CVE-2026-16796, que AWS indica para todas las versiones anteriores a la 1.18.1, usaba la sintaxis de extras de pip para colar comandos de shell. La corrección está en la 1.18.1. AWS asignó a ambas 7.3 en CVSS 3.1 y 8.4 en CVSS 4.0.

Según BeyondTrust, el aislamiento Firecracker de las sesiones resistió: el punto débil era el helper del SDK. Hacían falta tres condiciones: una entrada influida por el atacante que llegue a install_packages(), una versión vulnerable del SDK y un Code Interpreter personalizado con un rol de ejecución asociado. La entrada puede proceder de nombres de paquetes proporcionados por los usuarios, de contenidos no fiables procesados por el agente o de archivos de dependencias de un repositorio no fiable. En los registros de AWS, advierte BeyondTrust, la actividad del atacante puede parecer actividad legítima de la aplicación.

En la cadena descrita por Zenity, el agente llegaba al servicio de metadatos de la instancia (IMDS) y devolvía un conjunto completo de credenciales STS temporales (access key ID, secret access key y session token), que funcionaban también desde una máquina ajena a AgentCore. Quitar al agente la herramienta HTTP no bastaba: el fallo de aislamiento era de la plataforma, y el resultado se reproducía con otras herramientas, incluida la herramienta de shell integrada de Strands. Con permisos de lectura en ECR, los investigadores descargaron la imagen del agente, con su código y dependencias; como AgentCore nombra cada repositorio bedrock-agentcore-<nombre_agente>, en pocos segundos obtuvieron el código de todos los agentes de la región. El rol predeterminado tenía permisos de lectura, escritura y borrado sobre varios servicios de AgentCore y AWS de la región: invocar otros agentes, leer las conversaciones, envenenar la memoria para mantener la persistencia, recopilar credenciales y claves API y ejecutar acciones destructivas.

Ya en abril, Unit 42 había señalado que AgentCore Runtime usaba un servicio de metadatos de la microVM (MMDS) sin obligación de token de sesión: antes de las correcciones de AWS, una SSRF podía bastar para extraer credenciales.

Correspondencia indicativa con MITRE ATT&CK, basada en los hechos publicados: T1059 (Command and Scripting Interpreter), T1552.005 (Unsecured Credentials: Cloud Instance Metadata API), T1078.004 (Valid Accounts: Cloud Accounts).

Estado de las correcciones y posiciones divergentes

• Para las dos CVE del SDK, la corrección es la versión 1.18.1 o posteriores.
• Zenity comunicó los problemas a AWS el 25 de diciembre de 2025. El 14 de febrero de 2026, AWS pasó AgentCore a solo IMDSv2, cerrando el vector inicial, pero el 22 de junio los permisos del rol predeterminado seguían sin cambios. Según Zenity, se corrigieron entre el 22 de junio y el 29 de septiembre; el 8 de octubre la vía de ataque ya no era explotable.
• AWS cerró el informe de Unit 42 sobre AgentCore Harness como «informativo», en el marco del modelo de responsabilidad compartida.
• AWS sostiene que la investigación de Zenity presenta como vulnerabilidad un comportamiento esperado y documentado, y recomienda conceder a los roles de ejecución solo los permisos que necesitan los agentes.

Impacto para las empresas europeas e italianas

Quien usa AgentCore para agentes dirigidos a clientes o empleados está expuesto en proporción a los permisos del rol de ejecución: las credenciales robadas no se quedan en el sandbox. Si las conversaciones o claves afectadas contienen datos personales, hay que evaluar una violación de seguridad según el RGPD. Para las entidades sujetas a NIS2, los agentes de IA en la nube entran en las medidas del artículo 21: control de acceso, seguridad de la cadena de suministro y gestión de vulnerabilidades. Las fuentes coinciden en un punto: el aislamiento corresponde a la plataforma, pero los permisos son responsabilidad del cliente.

Qué hacer ya

1. Actualiza el SDK de Python de AgentCore a la 1.18.1 o posterior en proyectos, pipelines e imágenes.
2. No pases a install_packages() nombres de paquetes no fiables o generados por el modelo, como recomienda AWS.
3. Sustituye el rol de ejecución predeterminado por un rol por agente con solo los permisos necesarios; ningún rol donde el código no necesite servicios de AWS.
4. Revisa las herramientas integradas: desactiva la herramienta de shell de AgentCore Harness y las herramientas HTTP donde no hagan falta, y trata las que queden como de alto riesgo.
5. Limita el tráfico saliente de los agentes y no incluyas secretos en las imágenes.
6. Vigila la actividad: supervisa el Code Interpreter, define una referencia de identidad y herramientas de cada agente para que las anomalías destaquen, y busca en los registros de AWS el uso de las credenciales de los roles de los agentes fuera de su entorno habitual.

Última actualización: 8 de octubre de 2026