El 28 de octubre salieron dos reportes de seguridad sobre LangGraph, el framework que probablemente ya usas (o estás por usar) para construir agentes con memoria y flujos complejos. Uno de ellos, CVE-2026-118668, tiene un CVSS de 8.6: severidad alta. Si tienes un despliegue de LangGraph con autenticación personalizada en JavaScript o TypeScript, esto te toca directo, y no es un parche cosmético.
Qué pasó exactamente
La falla vive en langgraph-api, el componente que sirve los deployments de LangGraph. Cuando usas autenticación custom en JS o TS, tu handler puede devolver un namespace reescrito para aislar los datos de cada usuario dentro del Store (la memoria persistente de tus agentes). El problema: ese cambio de namespace no siempre cruzaba la frontera entre el runtime de JavaScript y el servidor antes de ejecutar la operación sobre el Store.
En la práctica, un usuario autenticado podía terminar leyendo, sobrescribiendo o incluso borrando el namespace de otro usuario, siempre que tu aislamiento dependiera de esa reescritura. No hace falta ser administrador, ni engañar a nadie, ni aprovechar una condición de carrera: el bug solo necesita que confíes en el namespace que te devuelve el handler sin validarlo después.
La otra falla: path traversal
Junto con esta, se publicó CVE-2026-118667, un path traversal en el propio LangGraph con CVSS 4.3 (severidad media). Es menos grave, pero confirma algo que conviene asumir de entrada: cualquier componente que mueva archivos, rutas o claves de usuario entre procesos es candidato a este tipo de error, y los frameworks de agentes no son la excepción solo porque son nuevos y suenan modernos.
Qué es el Store y por qué importa tanto
Si nunca trabajaste con LangGraph, el Store es la pieza que separa un chatbot que olvida todo al cerrar la pestaña de un agente que recuerda tus preferencias de hace tres semanas. A diferencia del checkpointer, que guarda el estado de una conversación puntual, el Store persiste información entre threads distintos: perfil del usuario, decisiones pasadas, documentos que ya procesó. Cada dato vive bajo un namespace, típicamente una tupla con el ID del usuario y algo de contexto adicional.
Ese namespace es justo el mecanismo que falló: si tu servidor confía en que el namespace que llega ya viene validado por el handler de autenticación, y el handler corre en un runtime distinto al que ejecuta la operación sobre el Store, se abre la ventana para que alguien lea datos que no le pertenecen. No es un bug exótico. Es el tipo de error que aparece cuando conectas dos sistemas (tu capa de auth y el motor de agentes) y asumes que la frontera entre ambos es más sólida de lo que realmente es.
No es solo un problema de LangGraph
CrewAI, AutoGen y cualquier otro framework de agentes que soporte memoria compartida entre usuarios enfrenta el mismo reto de diseño: aislar datos en un sistema multi-tenant es difícil, y se vuelve más difícil todavía cuando metes un LLM en el medio que puede, sin mala intención, terminar citando información de otro usuario porque estaba disponible en el contexto que le diste. La lección de este CVE aplica aunque uses otro framework: nunca asumas que el aislamiento de memoria entre usuarios viene gratis por default.
Por qué esto no es un detalle menor
El Store es justo lo que hace que un agente deje de ser un demo y se sienta útil: ahí vive la memoria entre sesiones, las preferencias del usuario, el historial que le da contexto a las decisiones. Si enseñas o aprendes LangGraph para construir agentes de verdad (no solo prototipos en un notebook), el aislamiento de ese Store entre usuarios es parte del diseño, no un extra que se agrega al final.
- ▸Afecta todas las versiones de langgraph-api desde la 0.1.2 hasta antes de la 0.15.0
- ▸Solo aplica si usas handlers de autenticación custom en JavaScript o TypeScript
- ▸El riesgo es real si tu aislamiento de usuarios depende de reescribir el namespace en vez de validarlo del lado del servidor
Qué significa un CVSS de 8.6 si no vienes de seguridad
El CVSS (Common Vulnerability Scoring System) va de 0 a 10 y mide qué tan fácil es explotar una falla y qué tan grave es el daño si alguien lo hace. Un 8.6 cae en el rango "alto": no hace falta ser un atacante sofisticado, no se necesita interacción del usuario ni condiciones especiales, y el impacto (leer o modificar datos de otro usuario) es serio. Para comparar, el path traversal de LangGraph con 4.3 es "medio": requiere más condiciones específicas para explotarse y el daño potencial es menor. No todos los CVE merecen la misma urgencia, y saber leer el score te ahorra pánico innecesario o, peor, calma injustificada.
Cómo proteger tus agentes ahora
El fix oficial llegó en langgraph-api 0.15.0: el servidor ahora valida el namespace después de que el handler lo reescribe y rechaza la operación si algo no cuadra. Si todavía no puedes subir de versión, la mitigación de emergencia es cambiar tus handlers para que rechacen namespaces no autorizados en vez de limitarse a reescribirlos y confiar en que nadie va a forzar la entrada.
Y si no usas auth custom en JS/TS, de todas formas vale la pena auditar tu lógica de aislamiento: trata el Store de tus agentes como tratarías una base de datos multi-tenant. Nunca confíes en un valor de namespace que viene del cliente sin volver a validarlo del lado del servidor.
- ▸Revisa la versión de langgraph-api que tienes en producción, no solo en el repo de desarrollo
- ▸Escribe una prueba que intente acceder al namespace de otro usuario simulando un token válido pero de otra cuenta
- ▸Si corres LangGraph en AWS, GCP o Azure, revisa también los logs de acceso al Store de las últimas semanas antes de dar por cerrado el tema
Un detalle que se pasa por alto: el CVSS de 8.6 asume el peor escenario posible, no que ya te explotaron. Si tu producto apenas tiene un puñado de usuarios de prueba, el riesgo real hoy es bajo. Pero si ya estás vendiendo acceso a un agente con memoria persistente, este parche no espera al próximo sprint de mantenimiento.
Lo que casi nadie dice en los tutoriales de LangGraph es que el Store se diseñó pensando en prototipos rápidos, no en aislar los datos de miles de usuarios desde el primer día. Si tu agente ya corre en producción con datos reales, la seguridad del Store deja de ser un detalle de arquitectura y pasa a ser un requisito del lanzamiento.
Cómo aprenderlo bien desde el inicio
Si estás armando el primer agente serio de tu equipo, conviene aprender la arquitectura completa (memoria, checkpointing, human-in-the-loop y ahora también aislamiento de datos) en vez de ir copiando snippets de la documentación. En nuestro taller práctico de LangGraph construyes un agente con memoria persistente desde cero, y si lo que buscas es el camino completo para especializarte en agentes de producción, la ruta AI Agentic Engineer cubre esto junto con orquestación multi-agente y despliegue real.
Si prefieres ir practicando esto semana a semana con gente que está resolviendo los mismos problemas, en la Comunidad AI Builders hacemos un taller en vivo cada semana, desde 19 USD al mes.
Puedes ver el resto de cursos de agentes y datos en nuestro catálogo y elegir por dónde empezar según el nivel que ya tengas.
