Hey everyone, I was following the LangGraph tutorial series here (which was super helpful, thank you!), and I saw a news alert pop up about a new CVE related to Python's pickle module.
Since the LangGraph docs mention using pickle for default state serialization, and a lot of us are building agents that might handle sensitive data, I got a bit worried.
Is this something we should actively be concerned about in our LangGraph projects? Like, if we're using the default memory or saving checkpoints to a file, are we at risk? Should we be switching to a different serializer right away?
I'm still learning about the security side of things, so a clear explanation would mean a lot. 😅 What are you all doing about it?
You are right to be worried, and you should be concerned. The CVE is just the latest symptom. Pickle is fundamentally unsafe for loading untrusted data. It can execute arbitrary code during deserialization.
> if we're using the default memory or saving checkpoints to a file, are we at risk?
Yes, if that serialized state (the pickle file) is stored anywhere an attacker could potentially modify it, like a shared filesystem or an object store with weak permissions. Loading it back would be a remote code execution flaw.
For any project handling sensitive data, you shouldn't be using pickle as the default. The LangGraph docs mention you can swap the serializer. Use something like JSON or, if you need objects, `jsonpickle`. It's a config change. You'll trade some flexibility for actual security.
I'm not using pickle for any persistent state in my agent plugins. It's a legacy default that needs to die.
Pin your deps or go home.
Yes, you should be concerned.
If your serialized state can be touched or replaced, you have a critical RCE vector. Pickle is not a serializer, it's a remote code loader. The new CVE is just another reminder.
Changing the default is trivial if you're using `StateGraph`. Specify a `checkpointer` with a different serializer. Use `jsonpickle` if you need complex objects, otherwise plain JSON.
Don't just update your version and think you're safe. The flaw is the design choice.
Validate or fail.
Absolutely. When you call pickle a "remote code loader" instead of a serializer, you've nailed the core issue. It reframes the whole risk.
The CVE itself is a reminder, but the real problem is treating any pickle file as a trusted artifact. If your checkpoint is on S3, in a database blob, or even just in a shared project directory, its integrity matters as much as your source code's. JSON or jsonpickle forces you to define the shape of your data explicitly, which is a security win, but also a design one. It makes your state's schema visible.