La memoria de tu agente de IA es una superficie de ataque. Check Point Research demostró que se puede ir de SQL injection a la ejecución remota de código a través del checkpointer de LangGraph. En Tech86 seguimos de cerca esta clase de vulnerabilidad: no es la primera vez que la capa de persistencia de agentes de IA se convierte en vector de compromiso.
La cadena: de SQL injection a RCE por la memoria del agente
LangGraph es uno de los frameworks de agentes más usados del ecosistema LangChain, con 50 millones de descargas mensuales según PyPI Stats. El checkpointer es el componente que da al agente memoria persistente: guarda el estado de la conversa, el contexto, las herramientas usadas. Es lo que permite al agente retomar desde donde se quedó.
Check Point Research descubrió dos CVE que forman una cadena de explotación completa, además de una CVE clasificada como defense-in-depth:
CVE-2025-67644 (CVSS 7.3 por el CNA; el NVD lo evaluó en 7.8): SQL injection en el checkpointer SQLite. La función _metadata_predicate() interpola filter keys en f-strings sin validación. El vector son las claves, no los valores. Las aplicaciones que aceptan filter keys no confiables en las búsquedas son vulnerables. Parche: langgraph-checkpoint-sqlite 3.0.1+.
CVE-2026-27022: la misma clase de inyección en el checkpointer Redis del ecosistema JavaScript/Node.js (@langchain/langgraph-checkpoint-redis). Mismo mecanismo, backend y runtime diferentes. CVSS 6.5 (CNA). El NVD aún no publicó una evaluación independiente.
CVE-2026-28277 (CVSS 6.8 por el CNA; el NVD lo evaluó en 7.2): deserialización insegura de msgpack durante la carga de checkpoints. El checkpointer reconstruye objetos Python a partir de datos msgpack. Si un atacante puede modificar los datos del checkpoint en el backing store, por ejemplo, tras comprometer la base de datos vía SQL injection, proporciona un payload que ejecuta código arbitrario cuando el checkpoint se carga. Parche: langgraph 1.0.10+.
La cadena es lineal: SQL injection → manipulación de los datos del checkpoint → deserialización msgpack → ejecución remota de código. Cada etapa habilita la siguiente.
El debate sobre defense-in-depth
El GitHub advisory clasifica la CVE-2026-28277 como "post-exploitation / defense-in-depth" y afirma que no hay evidencia de explotación en entorno real. Según la propia clasificación del advisory, eso es correcto como evaluación de severidad aislada.
Pero la cadena que Check Point documentó cambia el cálculo. El prerrequisito para la deserialización insegura, la escritura en el checkpoint store, es alcanzable vía SQL injection. La clasificación "defense-in-depth" solo se sostiene si el checkpointer no está expuesto a input no confiable. Si lo está, la cadena es completa y la severidad real es significativamente mayor de lo que sugiere la clasificación individual.
En Tech86 ya vimos esta dinámica: vulnerabilidades clasificadas como defense-in-depth que, en la práctica, forman cadenas completas de explotación. La clasificación correcta depende del contexto de deployment, no solo de la vulnerabilidad aislada.
El vector independiente: fallback a pickle
Además, la CVE-2026-27794, descubierta por Trend Micro Zero Day Initiative (ZDI), afecta al BaseCache en langgraph-checkpoint anterior a 4.0.0, que tiene fallback a pickle. Pickle es un formato de serialización de Python que permite la ejecución arbitraria de código por definición: es una propiedad documentada del formato.
Este fallback permite RCE directo, sin necesidad de SQL injection como paso previo. Es un vector independiente, separado de la cadena SQLi→RCE, y tan grave como ella. Cualquier deployment con langgraph-checkpoint anterior a 4.0.0 está expuesto, independientemente de que el checkpointer acepte input no confiable.
Quién está en riesgo
Los equipos que alojan LangGraph localmente con checkpointer SQLite o Redis y exponen get_state_history() con filtro controlado por el usuario. La nube gestionada de LangChain usa PostgreSQL y no es vulnerable a la cadena documentada, según el GitHub advisory y Check Point Research.
El perfil de riesgo es claro: si el deployment acepta filter keys no confiables, la cadena SQLi→RCE es completa. Si usa langgraph-checkpoint anterior a 4.0.0, el fallback pickle es un vector independiente. Muchos equipos encajan en los dos escenarios simultáneamente.
La mitigación que funciona
La mitigación principal es activar LANGGRAPH_STRICT_MSGPACK=true en producción. Esto cambia la política de deserialización a allowlist: solo los tipos seguros se reconstruyen a partir de datos msgpack. LangGraph puede derivar automáticamente la allowlist a partir de los schemas del grafo al compilar.
Además de la flag, es necesario aplicar los parches: langgraph-checkpoint-sqlite 3.0.1+, langgraph 1.0.10+ y langgraph-checkpoint 4.0.0+. Y restringir las filter keys en get_state_history(): nunca pases input del usuario directamente como claves de filtro.
La infraestructura que da memoria al agente da persistencia al atacante
Lo que el ecosistema de supply chain de IA ya mostró repetidamente ahora se repite en la capa de persistencia del agente. La infraestructura que da al agente memoria y continuidad es la misma que da al atacante persistencia y ejecución.
En Tech86 operamos con la premisa de que cada capa de infraestructura que añade funcionalidad al agente añade también superficie de ataque. El monitoreo continuo, el aislamiento de red y los parches aplicados no son opcionales: son el mínimo. Por eso nuestro EDR monitorea endpoints de IA en tiempo real, detectando patrones de explotación antes de que la cadena se complete.
Continúa en el tema
Segurança de Agentes de IA: Prompt Injection, Worms e Supply Chain →