As AI agents evolve from simple prompt-response systems into autonomous, stateful applications, memory persistence has become a critical architectural component. Modern AI frameworks increasingly rely on persistent storage mechanisms to maintain context, execution state, conversation history, and workflow checkpoints across sessions. One of the most widely adopted frameworks in this space is LangGraph, an extension of the LangChain ecosystem designed specifically for building stateful and multi-agent AI systems.
While persistent memory significantly enhances agent capabilities, it also introduces new attack surfaces. Recent security research uncovered a series of vulnerabilities within LangGraph’s checkpointer architecture that demonstrate how seemingly isolated weaknesses can be chained together into a complete remote code execution (RCE) attack path. The findings reveal the security implications of improper input handling, unsafe deserialization, and inadequate query construction within AI infrastructure components. This analysis examines the discovered vulnerabilities, their exploitation chain, affected environments, mitigation strategies, and broader lessons for AI security practitioners.
Understanding LangGraph’s Checkpointer Architecture
LangGraph provides built-in persistence through components known as checkpointers. These checkpointers function as storage engines that save workflow state at each stage of an agent’s execution lifecycle. By persisting state information, agents can resume execution, maintain memory across sessions, and support long-running workflows.
The framework supports multiple storage backends, including SQLite, PostgreSQL, and Redis implementations. During execution, checkpoints store serialized representations of workflow state alongside metadata that can later be queried and filtered by developers. This architecture enables features such as state history inspection, debugging, workflow recovery, and execution auditing. From a security perspective, however, any persistence layer that accepts user-influenced query parameters becomes a potential attack vector. The vulnerabilities identified within LangGraph demonstrate how metadata filtering functionality can become an entry point for much more severe compromise scenarios.
Vulnerability #1: SQL Injection in the SQLite Checkpointer (CVE-2025-67644)
The first vulnerability exists within LangGraph’s SQLite checkpointer implementation. The issue arises during metadata-based filtering operations used when retrieving checkpoint history. Checkpoint metadata is stored as JSON within the database and can contain contextual information such as user identifiers, execution steps, workflow source information, and application-specific state attributes. To support querying against this metadata, LangGraph dynamically constructs SQL predicates based on user-supplied filter parameters.
The root cause stems from insufficient sanitization of metadata field names before they are incorporated into SQL statements. Specifically, attacker-controlled keys within the filter dictionary are inserted directly into SQL expressions that reference JSON paths. Because these values are not properly parameterized, a malicious actor can inject SQL syntax into the generated query. This vulnerability transforms a seemingly harmless filtering mechanism into a full SQL injection primitive. An attacker capable of controlling filter parameters can manipulate query execution, alter result sets, and introduce malicious data into application processing flows. The issue demonstrates a common but dangerous anti-pattern in database interaction: dynamically constructing SQL statements using untrusted input instead of relying on parameterized queries. The significance of this vulnerability extends beyond traditional data disclosure or database manipulation. In this case, the injected SQL can be leveraged to introduce attacker-controlled records into query results, setting the stage for exploitation of a second vulnerability in the deserialization layer.
How SQL Injection Becomes an Arbitrary Deserialization Primitive
The SQLite checkpointer retrieves checkpoint records that contain serialized workflow state stored as binary objects. After query execution, each returned checkpoint is automatically deserialized before being processed by the application. Under normal operation, the database returns legitimate checkpoint data generated by trusted application workflows. However, SQL injection enables attackers to alter the result set through techniques such as UNION-based query manipulation.
By injecting a crafted record into the query response, an attacker can force the application to process a completely artificial checkpoint containing attacker-controlled serialized content. Since the application assumes all returned checkpoint records are trustworthy, the malicious payload proceeds directly into the deserialization pipeline. This attack pattern is particularly dangerous because it bridges two security domains. The initial SQL injection vulnerability provides data injection capabilities, while the downstream deserialization process provides code execution opportunities. Individually, each weakness is serious. Together, they create a highly impactful exploitation chain.
Vulnerability #2: Unsafe MsgPack Deserialization (CVE-2026-28277)
The second vulnerability resides within LangGraph’s serialization subsystem. The framework supports multiple serialization formats, including JSON and MsgPack. Among these, MsgPack presents the most significant security risk due to its support for custom extension types. LangGraph implements a custom MsgPack extension handler capable of dynamically reconstructing Python objects during deserialization. When processing certain extension types, the framework imports modules and invokes functions based on values embedded within serialized data.
The security flaw arises because these values are not sufficiently restricted. An attacker who controls serialized MsgPack content can specify arbitrary modules, arbitrary functions, and arbitrary arguments. During deserialization, the framework imports the requested module and executes the specified function with attacker-supplied parameters. From a security engineering perspective, this behavior effectively converts the deserialization process into a generalized code execution mechanism. The issue resembles historical unsafe deserialization vulnerabilities found across numerous programming languages and frameworks, where trusted object reconstruction logic inadvertently becomes an execution engine for malicious payloads. Because MsgPack payloads can contain instructions that invoke operating system functionality, successful exploitation can result in arbitrary command execution on the underlying server.
Building the Complete Attack Chain: SQL Injection to Remote Code Execution
The most critical aspect of this research is not either vulnerability individually, but the manner in which they can be combined into a complete attack chain. The attack begins when an application exposes state history functionality and allows user-controlled filter parameters. An attacker crafts a malicious filter object that exploits the SQLite SQL injection vulnerability. Instead of simply extracting information, the injected query introduces a fabricated checkpoint record into the database response.
This fabricated record contains a malicious MsgPack payload specifically designed to trigger unsafe deserialization behavior. When LangGraph processes the query results, it automatically attempts to deserialize the checkpoint content. At this stage, the second vulnerability is activated. The MsgPack extension handler interprets attacker-controlled instructions, imports arbitrary modules, and invokes arbitrary functions. Because these operations occur within the application’s execution context, the attacker gains the ability to execute commands on the host system. The result is a full remote code execution scenario originating from a metadata filtering interface that was never intended to provide direct access to system-level functionality.This attack chain highlights a recurring lesson in modern application security: high-severity compromises often emerge not from a single critical flaw but from the interaction of multiple lower-level weaknesses across different components.
Vulnerability #3: Redis Checkpointer SQL Injection (CVE-2026-27022)
Researchers also identified a parallel vulnerability affecting LangGraph’s Redis checkpointer implementation. Similar to the SQLite issue, user-controlled filter keys were incorporated directly into query logic without proper parameterization. Although the storage backend differs, the underlying vulnerability class remains the same: improper handling of untrusted input during query construction. Applications using Redis-based checkpoint persistence and exposing state history retrieval functionality may therefore face similar risks if untrusted users can influence filtering parameters. This finding demonstrates the importance of consistent security practices across all storage backends. Even when application logic appears identical, separate implementations often introduce unique security weaknesses that must be independently evaluated and tested.
Additional Security Findings and Defensive Improvements
Beyond the primary attack chain, researchers identified several additional query construction weaknesses affecting both SQLite and PostgreSQL implementations. Certain parameters, including values used for limits and time-to-live calculations, were incorporated directly into SQL statements rather than bound as parameters. While these issues may not have provided practical exploitation paths comparable to the primary vulnerabilities, they represented unnecessary attack surface and violated secure coding principles. The remediation effort therefore included broader adoption of parameterized query patterns across affected components. This approach reflects a mature security response strategy focused not only on patching specific vulnerabilities but also on eliminating entire categories of implementation risk.
Affected Environments and Exposure Assessment
Not every LangGraph deployment is vulnerable to the complete attack chain. Successful exploitation depends on several conditions. Organizations are primarily at risk when they self-host LangGraph using affected SQLite or Redis checkpointer implementations and expose checkpoint history retrieval functionality to users. Additionally, user-supplied filter parameters must be accepted without adequate validation or sanitization. Managed deployments operating on alternative persistence mechanisms are not affected by the documented attack path. Security teams should therefore assess exposure based on architecture, deployment model, storage backend selection, and API design rather than simply determining whether LangGraph is present in the environment.
Patch Availability and Recommended Remediation
The LangChain development team addressed the identified vulnerabilities through coordinated security updates. Organizations using affected components should prioritize upgrading to patched versions of the relevant packages. Security teams should also implement defense-in-depth measures, including strict input validation, parameterized query enforcement, least-privilege execution environments, secure deserialization policies, and continuous dependency monitoring. Beyond patching, organizations should review any API endpoints that expose state history functionality and ensure that user-controlled filtering capabilities are properly constrained.
Security Lessons for AI Infrastructure Teams
The vulnerabilities uncovered in LangGraph serve as a powerful reminder that AI systems inherit traditional application security risks while introducing entirely new attack surfaces. Persistence layers, memory systems, agent state management components, and workflow orchestration frameworks are becoming foundational infrastructure for modern AI applications. As these systems mature, attackers will increasingly target the underlying mechanisms that enable autonomous behavior and long-term memory.
Security teams should treat AI infrastructure with the same rigor applied to critical backend services. Threat modeling, secure coding practices, dependency auditing, deserialization reviews, and database security controls must all become standard components of AI application development. The future of AI security will depend not only on protecting models themselves but also on securing the surrounding ecosystem that enables intelligent, stateful, and autonomous execution.
Our Opinion
The LangGraph vulnerability chain represents one of the most important AI infrastructure security findings published in recent years. While many discussions around AI security focus on prompt injection, model jailbreaks, or data poisoning, this research shifts attention toward a less discussed but equally critical area: the security of the frameworks that power AI agents. What makes this case particularly significant is that the attack path relies on classic software security failures rather than AI-specific weaknesses. SQL injection and unsafe deserialization have existed for decades, yet they reappear within modern AI frameworks because developers often prioritize functionality and rapid innovation over secure architecture reviews.
We believe this research demonstrates that AI systems should not be viewed as isolated machine learning products. They are increasingly becoming full-stack applications composed of databases, APIs, serialization mechanisms, orchestration layers, memory engines, and third-party dependencies. Every one of these components can become an attack surface. The most valuable lesson is that AI security cannot be separated from traditional application security. Organizations adopting agentic AI must expand their security programs to include infrastructure-level assessments, dependency reviews, and secure coding practices. As AI agents gain greater autonomy and access to sensitive systems, vulnerabilities like these could have consequences far beyond data exposure, potentially enabling full environment compromise. The industry should treat AI infrastructure security as a top-tier priority moving forward.
