Check Point Research identificó una cadena de vulnerabilidades críticas en LangGraph, un marco de código abierto de los creadores de LangChain que permite a los desarrolladores crear flujos de trabajo de agentes de IA complejos, con estado y controlables mediante LLM ; tienen aproximadamente 46,5 millones de descargas mensuales, lo que la convierte en una de las plataformas de agentes de IA más utilizadas en el mundo.
Una inyección SQL en la función de LangGraph podría permitir a los atacantes obtener el control total de un servidor mediante la ejecución remota de código, aprovechando las vulnerabilidades en el procesamiento y manejo de datos del sistema. Un servidor LangGraph comprometido expone todo lo que el agente toca, incluyendo las claves API de LLM, los datos de los clientes, las credenciales de CRM, el historial de conversaciones y el acceso a la red interna.
Se asignaron tres vulnerabilidades CVE: CVE-2025-67644 (inyección SQLite), CVE-2026-28277 (ejecución remota de código mediante deserialización de msgpack) y CVE-2026-27022 (inyección Redis). Todas han sido parcheadas en versiones actualizadas.
La cadena de vulnerabilidades es explotable en implementaciones autoalojadas que utilizan el punto de control SQLite o Redis con entrada de filtro controlada por el usuario. La plataforma administrada de LangChain (Implementación LangSmith) no se ve afectada.
Esta investigación demuestra un patrón más amplio: las clases de vulnerabilidades clásicas, como la inyección SQL, se vuelven significativamente más peligrosas cuando aparecen dentro de marcos de agentes de IA que tienen acceso y confianza elevados.
Check Point Research descubrió cómo una única API que pasó desapercibida en LangGraph, uno de los marcos de trabajo para agentes de IA más utilizados en el mundo, puede otorgar a un atacante el control total de su infraestructura de IA.
LangGraph no es una herramienta de nicho. Con cerca de 46,5 millones de descargas solo el mes pasado, impulsa agentes de IA en miles de entornos de producción, desde la automatización de la atención al cliente hasta los flujos de trabajo internos de las empresas. Tal nivel de adopción significa que cualquier problema de seguridad que presente merece una atención especial.
Cuando Check Point Research se propuso comprender cómo los marcos de agentes de IA gestionan la persistencia y el estado, no esperábamos encontrar una vía para la ejecución remota completa de código. Pero eso es precisamente lo que descubrimos dentro de LangGraph, oculto en el componente responsable de guardar y recuperar la memoria del agente.
Cómo los agentes de IA recuerdan las cosas
A diferencia de un chatbot simple, un agente de IA con estado necesita recordar lo que ha hecho en múltiples pasos. LangGraph gestiona esto mediante un componente llamado punto de control, una capa de persistencia que guarda el estado de ejecución del agente en cada paso para que pueda recuperarse posteriormente.
Aquí es donde se centró nuestra investigación. El mecanismo de control de puntos de control está profundamente integrado en el funcionamiento de LangGraph, y cualquier vulnerabilidad en este punto se encuentra directamente en la ruta de ejecución de todo el flujo de trabajo del agente.
Nuestro equipo descubrió que la función get_state_history() de LangGraph, que recupera los puntos de control históricos de los agentes, contiene una vulnerabilidad de inyección SQL en su parámetro de filtro. Esto, por sí solo, ya es grave. Pero combinado con una segunda vulnerabilidad en la forma en que LangGraph deserializa los datos de los puntos de control, se convierte en una vía para la ejecución remota completa de código.
La cadena que lo hace peligroso
Los errores individuales son comunes. Lo que hace que esta investigación sea significativa es cómo dos vulnerabilidades se combinan para crear algo mucho más grave que cualquiera de ellas por separado. La inyección SQL permite a un atacante manipular los datos de punto de control que se devuelven desde la base de datos. La vulnerabilidad de deserialización implica que, cuando LangGraph procesa esos datos, se ejecuta en el servidor una carga útil controlada por el atacante como código. Ninguna de las vulnerabilidades por sí sola explica el problema por completo. Juntas, crean una ruta clara desde una simple llamada a la API hasta el compromiso total del servidor.
Se identificaron tres vulnerabilidades (CVE) en el sistema de control de SQLite, el sistema de control de Redis y el mecanismo de deserialización principal. Colaboramos directamente con el equipo de LangChain durante todo el proceso de divulgación, ayudando a diseñar y validar las soluciones.
Lo que realmente obtiene un atacante
La ejecución completa del código en un servidor LangGraph no es un incidente aislado. Estos servidores almacenan las claves de acceso a todo lo que el agente modifica.
Claves y secretos de la API de LLM: todas las claves que utiliza el agente, directamente facturables y susceptibles de ser utilizadas indebidamente por el atacante.
Historial completo de conversaciones: cada interacción, solicitud y respuesta que el agente haya procesado.
Datos conectados: registros de CRM, tickets de soporte técnico, detalles de facturación e información personal identificable del cliente que el agente haya manejado.
Punto de apoyo en la red: un punto de pivote hacia sistemas internos más amplios, heredando cualquier acceso que tuviera el agente.
Esto es radicalmente diferente de un ataque de inyección instantánea que afecta a una única sesión de agente. Un servidor comprometido permite a un atacante leer todas las conversaciones que el agente haya procesado y secuestrar por completo su comportamiento en adelante. Esto podría manipular la IA para que realice acciones no autorizadas, difunda desinformación o suplante la identidad de sistemas de confianza. En efecto, la IA pasa de ser un asistente de confianza a una herramienta potencialmente comprometida que puede generar graves riesgos operativos, de seguridad y de confianza para la organización.
¿Quiénes son los afectados?
LangGraph es un framework, no un producto alojado. Esto significa que cada equipo que lo utiliza lo aloja internamente en su propia aplicación. La cadena de vulnerabilidades se puede explotar cuando una aplicación expone `get_state_history()` con un parámetro de filtro configurable por el usuario y utiliza el backend de checkpointer SQLite o Redis. La plataforma gestionada de LangChain utiliza PostgreSQL y no se ve afectada por esta cadena específica.
Las tres vulnerabilidades han sido corregidas. Los equipos que utilizan el punto de control SQLite deben actualizar a langgraph-checkpoint-sqlite 3.0.1 o posterior para solucionar la vulnerabilidad CVE-2025-67644. El problema de deserialización de msgpack, CVE-2026-28277, está resuelto en langgraph 1.0.10 o posterior. Para quienes utilizan el punto de control Redis, la vulnerabilidad CVE-2026-27022 está parcheada en langgraph-checkpoint-redis 1.0.2 o posterior. Si utiliza una versión anterior a estas, actualizar el parche debe ser la prioridad inmediata para evitar cualquier impacto.
Garantizar la seguridad de la IA con capacidad de gestión de agentes: qué deben hacer los defensores.
Estas vulnerabilidades ya han sido corregidas y todos los usuarios deberían actualizar de inmediato. Pero la conclusión más importante de esta investigación es lo que revela sobre cómo los equipos deberían abordar la seguridad de los agentes de IA en general.
Aplique el parche inmediatamente: Si está utilizando una versión afectada de LangGraph, actualizarla es el paso más importante. Las versiones parcheadas se enumeran arriba.
Implemente la autenticación delante de su servidor LangGraph: LangGraph autoalojado no incluye autenticación integrada, lo que significa que la principal prioridad para los desarrolladores es colocar un proxy inverso o una puerta de enlace API delante del servidor y evitar la exposición directa a redes no confiables. Tratarlo como un servicio exclusivamente interno reduce significativamente la superficie de ataque.
Trate a los agentes de IA como identidades privilegiadas: los agentes tienen acceso real, interactúan con datos confidenciales y poseen credenciales para aplicaciones SaaS, API internas, bases de datos y proveedores de LLM. Un entorno de ejecución de agente comprometido debe tratarse con la misma gravedad que una cuenta privilegiada comprometida.
Minimice el acceso de los agentes: aplique el principio de mínimo privilegio a todas las credenciales que posea un agente. Cuanto menor sea el acceso restringido, más contenida estará cualquier vulneración. Las capacidades de seguridad de agentes de IA de Check Point se basan precisamente en este modelo, proporcionando visibilidad y control sobre el comportamiento del agente, la confianza en tiempo de ejecución y el riesgo de movimiento lateral en entornos de agentes.
Pruebe sus sistemas de agentes como lo harían los atacantes: Una de las lecciones más difíciles de esta investigación es que la gravedad provino de la cadena de fallos, no de un fallo aislado. Los errores individuales se detectan, pero las cadenas de fallos pasan desapercibidas. El equipo rojo de IA, que trata su pila de agentes como lo haría un adversario, es donde este tipo de riesgo emergente sale a la luz antes de que se convierta en un incidente real. El trabajo de equipo rojo de IA de Check Point se basa en este enfoque, utilizando el mismo razonamiento adversario que descubrió esta cadena de vulnerabilidades.
Evite secretos estáticos de larga duración: Siempre que sea posible, adopte patrones de intermediación de credenciales que reduzcan la exposición directa de la clave API y eviten que los secretos se filtren en las solicitudes, los registros o el estado del agente.
Implemente controles de red estrictos: Los entornos de ejecución de agentes deben estar protegidos por una autenticación y segmentación de red adecuadas, y no expuestos como puntos finales abiertos.
Read less 
Tabatinga
