Marcos de agentes de IA expuestos por 11 fallos clásicos

Once vulnerabilidades encontradas en marcos de agentes de IA muy utilizados apuntan a un problema de seguridad más profundo que la inyección de prompts o cualquier modelo individual, según investigadores de Check Point.

Los investigadores pasaron un año probando LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework y Google ADK. Encontraron y divulgaron 11 fallos, incluidos vulnerabilidades que podrían permitir ejecución remota de código, forjado de solicitudes del lado del servidor, travesía de directorios, deserialización insegura y ataques de uso tras liberación.

«Un error en un marco de agentes no es un error en un solo producto: es un fallo en la capa sobre la que se ejecuta toda una categoría de aplicaciones de IA. Y el agente no necesita herramientas peligrosas para volverse contra ti: leer el documento equivocado basta. Estamos construyendo esta capa más rápido de lo que sabemos defenderla.»

La inyección de prompts es solo el punto de partida

Yarden Porat y Shahar Tal de Check Point presentaron sus hallazgos en una charla del Black Hat el miércoles y los discutieron con The Register. Su argumento central es que los defensores deberían asumir que la inyección de prompts ocurrirá. La cuestión crítica es qué hace el marco con el contenido controlado por el atacante después.

En los sistemas vulnerables, el contenido de los prompts o documentos podía cruzar desde el plano de datos hacia la lógica de confianza del marco. Eso permitía que afectara la orquestación, la memoria, el estado, el enrutamiento y las instrucciones del sistema. El modelo en sí no era necesariamente el punto débil; lo era la infraestructura circundante.

«Casi ninguno de ellos era una clase de fallo completamente nueva. Eso es deserialización insegura, forjado de solicitudes del lado del servidor, travesía de directorios, uso tras liberación. Son fallos que aprendimos a corregir hace 20 años, y están debajo de agentes que ahora leen tu bandeja de entrada o actualizan tu base de datos.»

Esa distinción importa para los equipos que despliegan agentes de programación y flujos de trabajo empresariales. Como muestran las defensas contra la inyección de prompts de ReasonGate, bloquear instrucciones maliciosas es una capa de protección. La investigación de Check Point sugiere que los marcos también necesitan límites fuertes alrededor del estado, las herramientas y las API que procesan el contenido que un agente lee.

Recomendado

Atacante de Snowflake se declara culpable por un robo masivo de datos

Un fallo en el checkpoint de Microsoft permitió la ejecución de código

El ejemplo más grave implicó una vulnerabilidad crítica de deserialización en el checkpoint de Microsoft Agent Framework. Los agentes usan checkpoints para guardar instantáneas de su estado o progreso de tareas, incluido el historial de conversaciones, en almacenamiento persistente. Posteriormente pueden recargar esos datos después de un error o cuando un usuario rebobina una sesión.

Check Point descubrió que la inyección de prompts podía hacer que el agente cargara un checkpoint no confiable. Una carga maliciosa insertada por un usuario podría entonces ejecutarse cuando otro usuario rebobinara su propia sesión:

«El mensaje de una persona planta la carga útil, y luego otra persona rebobina su propia sesión, lo que activa la carga, y ahora el atacante tiene un shell en ese servidor.»

Microsoft reconoció el hallazgo, pagó una recompensa de $10,000 y lanzó protecciones para bloquear la vía de explotación demostrada. La empresa también actualizó el archivo de checkpoint relevante con un texto que define su límite de seguridad.

Microsoft no emitió un CVE porque el marco no era un producto disponible de forma general cuando Check Point descubrió el fallo. Eso deja el alcance preciso del software en pre-lanzamiento afectado menos claro de lo que sería para una vulnerabilidad ampliamente desplegada y catalogada.

Google ADK dejó una ruta sin autenticación expuesta

Los investigadores también encontraron un problema de límite de confianza en Google ADK, que incluye un asistente de desarrollo capaz de escribir archivos. Porat dijo que ese asistente seguía siendo accesible a través de una API HTTP aunque estuviera oculto en el listado de aplicaciones.

Un atacante podía abrir una sesión, pedir a ADK que escribiera un agente que contuviera código Python que se ejecuta durante la importación, y luego pedir al servidor que lo ejecutara. El servidor importaría el archivo y ejecutaría el código del atacante.

Check Point dijo que la API no tenía autenticación por defecto. Añadió que adk deploy cloud_run publica la misma API, haciéndola accesible sin credenciales en una implementación por defecto de Cloud Run. Desde ahí, el código podría alcanzar las claves de API del entorno y la cuenta de servicio de Google Cloud del contenedor.

Google no respondió a las consultas de The Register. Check Point dijo que Google inicialmente consideró que el problema no era un fallo, pero luego pagó una recompensa de $3,133.70 y emitió una solución parcial. Los investigadores dijeron que se centraron en las consecuencias —la ejecución de código que conduce al robo de secretos— en lugar de tratar el problema como una mera molestia para desarrolladores.

Las recompensas reportadas sumaron $17,133.70. La conclusión más amplia de Check Point no es que un marco sea particularmente inseguro: las mismas clases de vulnerabilidades antiguas aparecieron en los sistemas probados. Para los creadores de agentes empresariales, la inyección de prompts debe por tanto tratarse como una entrada esperada, mientras que el aislamiento del marco, la autenticación, la serialización y el manejo del estado se convierten en los controles de seguridad que determinan si esa entrada se mantiene como datos o llega a la máquina.