Python Pickle Deserialization Prevention Checklist
Python pickle modules execute arbitrary code during deserialization, meaning any untrusted data processed by these functions allows remote attackers to seize control of your system.

Never unpickle data from untrusted sources. Replace pickle with safe formats like JSON for configuration and logging. If you must use pickle, verify signatures or use allow-lists. This checklist provides specific controls to prevent remote code execution via deserialization flaws.
Why Python Pickle Is Dangerous
Python pickle is a serialisation module that converts Python objects into byte streams. It is designed for saving and loading Python-specific data structures. The mechanism does not distinguish between data and executable code. When the system unpickles a stream, it reconstructs the original objects. This process can invoke arbitrary methods or import modules.
An attacker who controls the input stream can craft a payload that executes commands on the host. The risk extends beyond simple data corruption. It enables full system compromise. You must treat pickle deserialization as a code execution vector. The assumption that pickle is only for data storage is incorrect. It is a potent execution engine.

Input Validation Controls
- Reject pickle data from external users: Untrusted inputs allow attackers to inject malicious payloads that execute during reconstruction.
- Implement strict allow-lists for modules: Restrict which modules the unpickler can import to prevent execution of system commands.
- Validate data schemas explicitly: Ensure the structure matches expectations to catch malformed or unexpected object types early.
- Check data integrity with hashes: Verify that the payload has not been altered in transit to detect tampering attempts.
- Limit payload size strictly: Prevent resource exhaustion attacks that could disrupt service availability or mask malicious content.
Safe Alternatives to Pickle
- Use JSON for configuration data: JSON is a text-based format that does not execute code, removing the execution risk entirely.
- Adopt MessagePack for binary data: This format provides efficient binary serialisation without the code execution capabilities of pickle.
- Utilise Protocol Buffers for APIs: This standard offers strong typing and efficiency while keeping data and logic separate.
- Replace pickle in logging systems: Log data should be plain text or structured JSON to prevent log injection and deserialization attacks.
- Migrate cache storage formats: Redis and Memcached should store JSON or string data rather than pickled objects to protect backend services.
Application Architecture Defences
- Apply least privilege to processes: Run services with minimal permissions to limit the impact if deserialization is exploited.
- Use application sandboxing: Isolate deserialization logic in a restricted environment to contain potential code execution.
- Implement network segmentation: Separate systems that handle untrusted data from critical infrastructure to reduce lateral movement.
- Enable runtime application self-protection: Deploy tools that monitor for suspicious behaviour during the deserialization process.
- Review code for insecure patterns: Identify and refactor any use of pickle.loads or pickle.Unpickler on untrusted inputs.
Verification and Testing
- Integrate static analysis tools: Scan codebases for pickle usage patterns to identify potential deserialization vulnerabilities early.
- Perform dynamic security testing: Test applications with malicious payloads to verify that deserialization controls are effective.
- Conduct regular secure code review: Have experts examine code handling data serialisation to find logical flaws missed by automated tools.
- Monitor for anomalous behaviour: Watch for unexpected process creation or network connections following deserialization events.
- Update dependencies regularly: Keep Python libraries up to date to benefit from security patches and improved safety features.
Operational Hygiene
- Document data flow diagrams: Map how data enters, is processed, and leaves the system to identify deserialization risks.
- Train developers on risks: Educate teams on why pickle is dangerous and which alternatives are safe for data exchange.
- Establish incident response plans: Prepare procedures to detect and respond to deserialization-based attacks quickly and effectively.
- Audit third-party libraries: Ensure that external dependencies do not introduce unsafe deserialization practices into your application.
- Review access controls regularly: Ensure that only authorised processes can trigger deserialization operations on sensitive data.
Key takeaways
- Pickle deserialization executes arbitrary Python code, creating a high-risk vector for remote code execution.
- Safe alternatives like JSON handle data exchange without executing code, eliminating the primary attack surface.
- Application-level controls such as input validation and sandboxing provide defence in depth when migration is not possible.
Python pickle deserialization executes arbitrary code, making it a critical security risk. Replace pickle with safe formats like JSON and validate all inputs to prevent remote code execution.
Frequently asked questions
Can I safely use pickle for internal data?
No. Internal data sources can be compromised. Treat all deserialization as potentially hostile. Use safe formats like JSON instead.
Does hashing prevent pickle attacks?
Hashing verifies integrity but not safety. A valid hash does not prevent malicious code within the payload from executing. You must validate the content.
What is the best alternative to pickle?
JSON is the best alternative for most use cases. It is widely supported, human-readable, and does not execute code during deserialization.
How do I find pickle vulnerabilities in code?
Use static analysis tools to scan for pickle.loads or pickle.Unpickler. Review code handling untrusted inputs manually to ensure proper validation.
How this guide was produced: written by the Malware Brief editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.



