LangGraph en jaque por tres vulnerabilidades críticas que pueden permitir ejecución remota de código en instalaciones autoalojadas

Autor: Publicada 4 min de lectura 194 lecturas

Las imágenes de este artículo han sido generadas con inteligencia artificial. Cómo publicamos

Investigadores de seguridad han revelado tres vulnerabilidades ya corregidas en LangGraph, el framework de código abierto desarrollado por LangChain para construir agentes de IA con estado y multi-agente. La más crítica es una cadena de fallos —SQL injection más deserialización insegura— que, en instalaciones self-hosted, puede permitir la ejecución remota de código (RCE) si la aplicación expone determinados endpoints y emplea los módulos de persistencia afectados.

Las fallas identificadas incluyen CVE-2025-67644, una inyección SQL en la implementación SQLite del checkpointer que permite manipular consultas a través de filtros de metadatos (afecta a langgraph-checkpoint-sqlite antes de la versión 3.0.1); CVE-2026-28277, una deserialización insegura de msgpack que abre la puerta a reconstrucción de objetos maliciosos al cargar checkpoints (afecta a langgraph antes de la versión 1.0.10); y CVE-2026-27022, una inyección en consultas RediSearch que puede eludir controles de acceso en @langchain/langgraph-checkpoint-redis (antes de la versión 1.0.1). Los descubrimientos fueron atribuidos al investigador Yarden Porat y publicados junto a análisis de Check Point.

LangGraph en jaque por tres vulnerabilidades críticas que pueden permitir ejecución remota de código en instalaciones autoalojadas
Imagen generada con IA.

El vector de ataque más serio descrito por los investigadores combina primero la inyección SQL para devolver una fila de checkpoint falsificada y luego fuerza la aplicación a deserializar un BLOB msgpack controlado por el atacante, lo que puede ejecutar el payload incrustado. Ese encadenamiento depende de que el servicio permita leer checkpoints por metadatos (por ejemplo, mediante get_state_history()) y de la capacidad del atacante para influir en los filtros o en los datos del almacén de checkpoints.

Es importante subrayar que las configuraciones gestionadas por LangChain (LangSmith Deployment) no se ven afectadas por este escenario en el modelo de amenaza descrito, porque los entornos típicos alojados no permiten la manipulación directa del almacenamiento de checkpoints. No obstante, en despliegues propios (self-hosted) la exposición de endpoints sin autenticación y la falta de protecciones en la capa de persistencia pueden convertir fallos clásicos como SQL injection en vectores críticos contra infraestructuras de IA.

Desde el punto de vista práctico, los operadores deben priorizar la aplicación de las actualizaciones publicadas por LangGraph y LangChain. Actualizar a langgraph 1.0.10, langgraph-checkpoint-sqlite 3.0.1 y @langchain/langgraph-checkpoint-redis 1.0.1 (o versiones superiores) cierra estas vulnerabilidades conocidas. Además, conviene revisar la telemetría y los logs para detección retrospectiva de consultas o checkpoints sospechosos y auditar accesos al almacén de checkpoints.

Más allá del parche inmediato, las mitigaciones compensatorias son claves: habilitar autenticación y autorización robusta en cualquier endpoint que exponga historial o checkpoints; evitar secretos estáticos de larga duración en runtimes de agentes; segmentar las redes para que los servicios de almacenamiento (SQLite/Redis) no queden accesibles desde zonas públicas; y aplicar el principio de menor privilegio a los agentes, tratándolos como identidades privilegiadas con acceso restringido a recursos específicos.

LangGraph en jaque por tres vulnerabilidades críticas que pueden permitir ejecución remota de código en instalaciones autoalojadas
Imagen generada con IA.

En el nivel de desarrollo, es imprescindible corregir la raíz: usar consultas parametrizadas y validación estricta de los filtros antes de incorporarlos a consultas SQL, introducir firma o integridad de checkpoints para impedir la carga de datos manipulados, y sustituir o mitigar deserialización insegura mediante formatos seguros o validaciones estrictas. Para la deserialización de datos binarios se recomienda verificar esquemas, usar bibliotecas que impongan límites y, cuando sea posible, evitar la ejecución de código a partir de objetos reconstruidos.

Los operadores que no puedan parchear inmediatamente deberían al menos deshabilitar o proteger el endpoint get_state_history(), restringir el acceso a la base de datos y al servicio Redis desde redes no confiables, rotar credenciales y claves, y establecer monitoreo y alertas sobre operaciones inusuales en la capa de persistencia. Considerar el uso de entornos de ejecución aislados y la prohibición de privilegios innecesarios reduce el impacto de una posible escalada.

Este caso vuelve a poner en primer plano que vulnerabilidades bien conocidas (inyección SQL, deserialización insegura) cobran una nueva dimensión cuando se encuentran dentro de frameworks de agentes de IA que manejan secretos, credenciales y conexiones a otros sistemas. Para más contexto sobre ataques de deserialización y buenas prácticas contra inyección SQL, consulte la guía de OWASP sobre deserialización insegura y la documentación de OWASP sobre inyección SQL. Para información y comunicados del descubrimiento y las correcciones, puede revisar el aviso de los investigadores y el repositorio de LangChain en GitHub: Check Point Research, OWASP, GitHub - LangChain.

Cobertura

Relacionadas

Mas noticias del mismo tema.