Cadena de explotación en LangGraph permite RCE en despliegues self-hosted

Investigadores de Check Point revelaron tres vulnerabilidades ya corregidas en LangGraph, el framework abierto de LangChain para crear aplicaciones de IA multiagente. Según los investigadores, dos de ellas pueden combinarse en una cadena de explotación que conduce a ejecución remota de código (RCE) en servidores con despliegues self-hosted. Las vulnerabilidades afectan a los componentes de almacenamiento de puntos de control (checkpointer) para SQLite y Redis. La plataforma gestionada LangSmith, según se informa, no es vulnerable a estos problemas. Los usuarios de instalaciones self-hosted deben actualizar de inmediato los paquetes afectados.

Vulnerabilidades descubiertas

Las tres vulnerabilidades fueron descubiertas por el investigador Yarden Porat de Check Point y se documentan en el informe técnico de la compañía. Cada una tiene un identificador CVE independiente y está confirmada en las recomendaciones de GitHub Security Advisory:

• CVE-2025-67644 (CVSS 7.3): SQL injection en la implementación de puntos de control para SQLite. Un atacante puede manipular las consultas SQL a través de claves de filtros de metadatos. Se ven afectadas las versiones de langgraph-checkpoint-sqlite anteriores a la 3.0.1.
• CVE-2026-28277 (CVSS 6.8): deserialización insegura de msgpack en LangGraph, que permite iniciar la reconstrucción de objetos al cargar un punto de control con datos modificados. Se ven afectadas las versiones de langgraph anteriores a la 1.0.10.
• CVE-2026-27022 (CVSS 6.5): inyección de consultas RediSearch en @langchain/langgraph-checkpoint-redis, que permite eludir los mecanismos de control de acceso. Se ven afectadas las versiones anteriores a la 1.0.1.

Cabe destacar que ninguna de las vulnerabilidades, considerada de forma aislada, alcanza un nivel crítico en la escala CVSS. Sin embargo, es precisamente su combinación lo que genera la amenaza más grave.

Mecanismo de la cadena de explotación: de SQL injection a RCE

Según Check Point, CVE-2025-67644 y CVE-2026-28277 pueden combinarse en una cadena para lograr ejecución remota de código. La condición necesaria es que la aplicación proporcione acceso al endpoint get_state_history(), que permite extraer puntos de control históricos en función de sus metadatos.

La secuencia del ataque es la siguiente:

1. El atacante forma una carga útil en formato msgpack que contiene instrucciones para ejecutar código arbitrario.
2. Mediante SQL injection en los parámetros del filtro, el atacante sustituye el resultado de la consulta a la base de datos, devolviendo una fila de punto de control falsa en la que la columna checkpoint contiene datos serializados controlados por el atacante.
3. La aplicación procesa el resultado de la consulta y deserializa el BLOB de punto de control malicioso.
4. La deserialización insegura conduce a la ejecución de la carga útil del atacante en el servidor.

El aspecto clave de esta cadena es que la SQL injection clásica se convierte en vector de entrega para explotar la vulnerabilidad de deserialización. Sin la primera vulnerabilidad, la segunda requeriría acceso directo de escritura al almacenamiento de puntos de control, lo que reduce significativamente la superficie de ataque.

Posición de los desarrolladores y alcance de la amenaza

Los mantenedores de LangGraph caracterizaron CVE-2026-28277 como un problema de post-explotación: para utilizarla con éxito es necesario contar con la capacidad de escritura de datos controlados por el atacante en el almacenamiento de puntos de control. Según su evaluación, las configuraciones típicas de hosting gestionado están diseñadas para impedir este tipo de acceso.

La cadena de explotación es aplicable en despliegues self-hosted que usen SQLite o Redis como almacenamiento de puntos de control, siempre que la entrada de usuario se transmita a los parámetros de filtrado. La plataforma gestionada LangSmith Deployment, según se informa, no se ve afectada por estas vulnerabilidades. En el momento de la divulgación no se habían detectado indicios de explotación activa en entornos reales.

Evaluación del impacto

Las organizaciones más expuestas al riesgo son aquellas que han desplegado LangGraph en su propia infraestructura para construir agentes de IA con acceso a sistemas internos. En caso de explotación exitosa, el atacante obtiene la capacidad de ejecutar código arbitrario en el entorno de ejecución del agente, lo que puede derivar en la filtración de secretos en tiempo de ejecución y en acceso a otros sistemas a los que el agente tenga alcance.

Este caso demuestra de forma clara cómo clases de vulnerabilidades tradicionales —SQL injection y deserialización insegura— adquieren mayor peligrosidad en el contexto de los frameworks de agentes de IA. Los agentes suelen operar con privilegios y niveles de confianza ampliados, por lo que la compromisión de su entorno de ejecución resulta significativamente más destructiva que la de una aplicación web convencional.

Recomendaciones de mitigación

• Actualice los paquetes afectados: langgraph-checkpoint-sqlite a la versión 3.0.1 o superior, langgraph a la 1.0.10 o superior, y @langchain/langgraph-checkpoint-redis a la 1.0.1 o superior.
• Implemente autenticación para los servidores LangGraph self-hosted: endpoints como get_state_history() no deben estar disponibles sin autorización.
• Excluya secretos estáticos de larga duración del entorno de ejecución de los agentes; utilice rotación de credenciales.
• Aplique segmentación de red: aísle el entorno de ejecución de los agentes de IA de los sistemas internos críticos.
• Considere a los agentes de IA como identidades privilegiadas y aplique el principio de mínimos privilegios para limitar su acceso.
• Valide la entrada del usuario antes de pasarla a los parámetros de filtrado de puntos de control; no confíe exclusivamente en la protección a nivel de framework.

Las organizaciones que utilicen LangGraph en configuraciones self-hosted deberían dar prioridad a la actualización de los tres componentes afectados y realizar una auditoría de la accesibilidad de los endpoints de gestión del estado de los agentes. Incluso en ausencia de explotación confirmada en entornos reales, la existencia de una descripción técnica detallada de la cadena de ataque por parte de Check Point reduce significativamente la barrera de entrada para potenciales atacantes.