From SQLi to RCE – Exploiting LangGraph’s Checkpointer

FROM SQLI TO RCE – EXPLOITING LANGGRAPH’S CHECKPOINTER June 11, 2026 By Yarden Porat AI agents need memory. Frameworks like LangGraph provide it through checkpointers – persistence layers that store execution state. But what happens when that persistence layer isn’t locked down? Key Points Check Point Research analyzed LangGraph, an open-source framework for stateful AI agents with over 50 million monthly downloads, and uncovered three vulnerabilities in its persistence layer. Two of them chain into remote code execution: a SQL injection in the SQLite checkpointer (CVE-2025-67644) and an unsafe msgpack deserialization (CVE-2026-28277). A third, parallel issue (CVE-2026-27022) introduces the same injection class into the Redis checkpointer. Who’s at risk: teams self-hosting LangGraph with the SQLite or Redis checkpointer, where the application exposes get_state_history() with a user-controlled filter. LangChain’s managed cloud service, LangSmith Deployment (formerly LangGraph Platform), runs PostgreSQL and is not vulnerable. LangChain patched all three issues. Users should update to langgraph-checkpoint-sqlite 3.0.1+, langgraph 1.0.10+, and langgraph-checkpoint-redis 1.0.2+. Background LangGraph is an open-source framework for building stateful, multi-agent AI systems with built-in persistence. It’s an extension of LangChain, with over 50 million monthly downloads according to PyPI stats. Checkpointers are LangGraph’s persistence layer that stores execution state at each step. LangGraph supports two checkpointer implementations: SQLite and PostgreSQL. Vulnerability #1: SQL Injection (CVE-2025-67644) The SQLite Checkpointer Database Schema: The SQLite checkpointer uses an internal table called checkpoints with the following structure: CREATE TABLE checkpoints ( thread_id TEXT NOT NULL, checkpoint_ns TEXT NOT NULL DEFAULT '', checkpoint_id TEXT NOT NULL, parent_checkpoint_id TEXT, type TEXT, checkpoint BLOB, metadata BLOB, PRIMARY KEY (thread_id, checkpoint_ns, checkpoint_id) ); The metadata column stores additional contextual information about each checkpoint in JSON format. For example: { "user_id": "alice", "step": 1, "source": "input" } The list() Function and Filtering: When calling the list() function on sqliteSaver (the checkpointer), the filter parameter is used to query checkpoints based on their metadata: def list( self, config: RunnableConfig | None, *, filter: dict[str, Any] | None = None, # Used to filter by metadata before: RunnableConfig | None = None, limit: int | None = None, ) -> Iterator[CheckpointTuple]: The filter parameter is passed to an internal function called _metadata_predicate, which constructs the SQL WHERE clause to query checkpoints by their metadata fields. # process metadata query for query_key, query_value in filter.items(): operator, param_value = _where_value(query_value) predicates.append( f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}" ) param_values.append(param_value) return (predicates, param_values) The Injection The vulnerability exists in how _metadata_predicate handles the query_key from the filter dictionary. Notice this critical line: f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}" An attacker-controlled filter could provide a query_key with a ' character that will escape the JSON path string and inject arbitrary SQL code. Injection -> Arbitrary Deserialization To understand how SQL injection leads to arbitrary deserialization, we need to see the complete picture. Here’s the SQL query that gets executed in list(): query = f"""SELECT thread_id, checkpoint_ns, checkpoint_id, parent_checkpoint_id, type, checkpoint, metadata FROM checkpoints {where} ORDER BY checkpoint_id DESC""" This query retrieves checkpoint data from the database, including the checkpoint’s BLOB column. The results are then processed: async for ( thread_id, checkpoint_ns, checkpoint_id, parent_checkpoint_id, type, checkpoint, # ← This comes directly from the SQL query results metadata, ) in cur: # ← cur contains the query results # ... yield CheckpointTuple( # ... self.serde.loads_typed((type, checkpoint)), # ← Deserialization # ... ) The checkpoint contains serialized data, and when fetched gets deserialized. The Attack Using SQL injection in the WHERE clause, an attacker can inject a UNION SELECT that adds their own row to the query results: SELECT thread_id, checkpoint_ns, checkpoint_id, parent_checkpoint_id, type, checkpoint, metadata FROM checkpoints WHERE ... (injected: ') UNION SELECT 'thread1', 'ns', 'checkpoint1', NULL, 'msgpack', X'', '{}' -- ) ORDER BY checkpoint_id DESC The injected UNION SELECT returns a fake checkpoint row where the checkpoint column contains attacker-controlled serialized data. When the code loops through the query results, it deserializes this malicious checkpoint’s BLOB, giving the attacker arbitrary deserialization Vulnerability #2: MsgPack Unsafe Deserialization (CVE-2026-28277) Now let’s examine what happens during deserialization. The self.serde.loads_typed() function that deserializes checkpoint data looks like this: def loads_typed(self, data: tuple[str, bytes]) -> Any: type_, data_ = data if type_ == "null": return None elif type_ == "bytes": return data_ elif type_ == "bytearray": return bytearray(data_) elif type_ == "json": return json.loads(data_, object_hook=self._reviver) elif type_ == "msgpack": return ormsgpack.unpackb( data_, ext_hook=self._unpack_ext_hook, option=ormsgpack.OPT_NON_STR_KEYS ) elif self.pickle_fallback and type_ == "pickle": return pickle.loads(data_) else: raise NotImplementedError(f"Unknown serialization type: {type_}") Formats Pickle –  is disabled by default JSON –  The json.loads() with object_hook was discussed in our LangGrinch research, but does not lead to code execution Msgpack – This is the one we are interested in What is msgpack? MessagePack (msgpack) is a binary serialization format designed to be faster and more compact than JSON. LangGraph uses ormsgpack, a Rust-based implementation with Python bindings. Msgpack Extensions MessagePack allows developers to define custom extension types to handle additional data types beyond its built-in primitives. LangGraph implemented its own extension handler to support serialization of custom Python objects. When the type_ is msgpack, the code calls: ormsgpack.unpackb(data_, ext_hook=self._unpack_ext_hook, option=ormsgpack.OPT_NON_STR_KEYS) ``` The `ext_hook` parameter points to LangGraph's custom implementation: `_msgpack_ext_hook`. ```python def _msgpack_ext_hook(code: int, data: bytes) -> Any: if code == EXT_CONSTRUCTOR_SINGLE_ARG: try: tup = ormsgpack.unpackb( data, ext_hook=_msgpack_ext_hook, option=ormsgpack.OPT_NON_STR_KEYS ) # module, name, arg return getattr(importlib.import_module(tup[0]), tup[1])(tup[2]) except Exception: return When an attacker controls the serialized data, they control both the extension code and the data bytes. The vulnerability If we pass a msgpack with EXT_CONSTRUCTOR_SINGLE_ARG code, and the tuple: os system Command (“echo PWN > /tmp/pwned.txt” for example) When this line executes: return getattr(importlib.import_module(tup[0]), tup[1])(tup[2]) It will: 1. Import the os module 2. Get the system function from it 3. Call os.system("echo PWN > /tmp/pwned.txt") This gives an attacker arbitrary code execution – by calling os.system() with attacker-controlled commands, they can execute any shell command on the server. The Attack Chain: Combining Both Vulnerabilities Now let’s walk through how an attacker chains these two vulnerabilities together to achieve remote code execution. The Entry Point: When a developer exposes get_state_history(), it internally calls the checkpointer’s list() method to retrieve historical checkpoints: def get_state_history( self, config: RunnableConfig, *, filter: Optional[Dict[str, Any]] = None, before: Optional[RunnableConfig] = None, limit: Optional[int] = None, ) -> Iterator[StateSnapshot]: # ... for checkpoint_tuple in self.checkpointer.list(config, filter=filter, before=before, limit=limit): # Process and return checkpoint data If the filter parameter comes from user input without sanitization, an attacker controls the dictionary keys passed to the SQL injection vulnerability. The Attack Flow 1. Craft Malicious Payload: The attacker prepares a msgpack payload containing instructions to execute arbitrary code (e.g., run a shell command). 2. Exploit SQL Injection: The attacker sends a malicious filter parameter that exploits the SQL injection vulnerability. This injection adds a fake checkpoint row to the database query results, where the checkpoint column contains their malicious msgpack payload. 3. Trigger Deserialization: When the application processes the query results, it encounters the injected fake checkpoint and deserializes the malicious msgpack data. 4. Code Execution: The unsafe deserialization executes the attacker’s payload, giving them remote code execution on the server. Vulnerability #3: SQL Injection in the Redis Checkpointer (CVE-2026-27022) The same injection class affects langgraph-checkpoint-redis: user-controlled keys in the filter dictionary are interpolated directly into the query instead of bound as parameters. Preconditions match CVE-2025-67644 (the application exposes get_state_history() with a user-controlled filter and uses the Redis checkpointer). Patched in langgraph-checkpoint-redis 1.0.2. Additional SQL Injection Findings Beyond the primary SQL injection in the filter parameter, we identified additional defense-in-depth SQL injection issues in both the SQLite and PostgreSQL checkpointers. These involved direct concatenation of integer values (such as LIMIT and ttl parameters) into SQL queries instead of using parameterized bindings. Since Python doesn’t enforce type hints at runtime, these parameters could still accept malicious string input. We worked with the LangChain team during disclosure to remediate these issues using parameterized queries. Disclosure Timeline 2025-11-19: CVE-2025-67644 (SQL injection), CVE-2026-28227 (msgpack deserialization) And CVE-2026-27022 (Redis injection) disclosed to LangChain team 2025-12-10: CVE-2025-67644 fixed and publicly released in langgraph-checkpoint-sqlite 3.0.1 2026-02-20: CVE-2026-27022  fixed and publicly released in langgraph-checkpoint-redis 1.0.2 2026-03-05: CVE-2026-28277  fixed and publicly released in langgraph-checkpoint 4.0.1 Note on Vendor Response The LangChain team responded quickly to fix the critical SQL injection vulnerability, which effectively breaks the attack chain described in this research. They continue to work methodically on additional remediation efforts, including the msgpack deserialization issue. Additional Research There was significant community research into LangGraph security during November and December 2025. Other security researchers independently discovered CVE-2025-67644 and CVE-2026-28277. Full credits can be found in LangChain’s security advisories. GO UP POPULAR POSTS ARTIFICIAL INTELLIGENCE CHATGPT CHECK POINT RESEARCH PUBLICATIONS OPWNAI : Cybercriminals Starting to Use ChatGPT CHECK POINT RESEARCH PUBLICATIONS THREAT RESEARCH Hacking Fortnite Accounts ARTIFICIAL INTELLIGENCE CHATGPT CHECK POINT RESEARCH PUBLICATIONS OpwnAI: AI That Can Save the Day or HACK it Away BLOGS AND PUBLICATIONS CHECK POINT RESEARCH PUBLICATIONS August 11, 2017 “THE NEXT WANNACRY” VULNERABILITY IS HERE CHECK POINT RESEARCH PUBLICATIONS March 12, 2026 “HANDALA HACK” – UNVEILING GROUP’S MODUS OPERANDI CHECK POINT RESEARCH PUBLICATIONS GLOBAL CYBER ATTACK REPORTS THREAT RESEARCH February 17, 2020 “THE TURKISH RAT” EVOLVED ADWIND IN A MASSIVE ONGOING PHISHING CAMPAIGN CHECK POINT RESEARCH PUBLICATIONS August 11, 2017 “THE NEXT WANNACRY” VULNERABILITY IS HERE CHECK POINT RESEARCH PUBLICATIONS March 12, 2026 “HANDALA HACK” – UNVEILING GROUP’S MODUS OPERANDI CHECK POINT RESEARCH PUBLICATIONS GLOBAL CYBER ATTACK REPORTS THREAT RESEARCH February 17, 2020 “THE TURKISH RAT” EVOLVED ADWIND IN A MASSIVE ONGOING PHISHING CAMPAIGN CHECK POINT RESEARCH PUBLICATIONS August 11, 2017 “THE NEXT WANNACRY” VULNERABILITY IS HERE 123 We use cookies and similar technologies to operate our website, improve your experience, and support analytics and advertising. You can manage your preferences at any time. For more information, please see our Privacy Policy and Cookie Notice. Do Not Sell or Share My Personal Data When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. While this information may not directly identify you by name, it may include online identifiers (such as browser or device information) but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer. More information Allow All Manage Consent Preferences Strictly Necessary Cookies Always Active These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies are generally required for the operation of the website and are not used for marketing purposes. Performance Cookies Performance Cookies These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. We use this information in aggregated form to help us understand how the website is used and to improve its performance. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance. Functional Cookies Functional Cookies These cookies enable the website to provide enhanced functionality and personalization. They may be set by us or by third party providers (such as service providers supporting website functionality or content) whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly. Targeting Cookies Targeting Cookies These cookies may be set through our site by our advertising partners. They may be used to help deliver content and advertisements that are more relevant to your interests, including across different online services. They may use identifiers associated with your browser or device for this purpose. If you do not allow these cookies, you may receive less relevant advertising. Performance Cookies Clear checkbox label label Apply Cancel Consent Leg.Interest checkbox label label checkbox label label checkbox label label Reject All Confirm My Choices