Executive Summary

CVE-2026-33155 is a high-severity denial-of-service (DoS) vulnerability in the Python package DeepDiff, affecting versions 5.0.0 through 8.6.1. The issue lies in the _RestrictedUnpickler class used for safe deserialization of pickle data. While it restricts which classes can be loaded, it does not limit the size of constructor arguments passed during unpickling.

Some allowed classes, such as builtins.bytes, builtins.list, and builtins.range, have constructors that allocate memory proportional to their input size. An attacker can craft a small pickle payload (~40 bytes) that causes the application to allocate extremely large amounts of memory (e.g., 10+ GB), leading to crashes due to out-of-memory conditions.

There are two exploitation paths: one during direct pickle loading where large memory allocations occur, and another during delta application where malicious changes convert values to large bytes objects without size checks.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can cause a denial of service by exhausting system memory when an application deserializes untrusted pickle data or applies malicious delta objects. The crafted payloads can force the application to allocate gigabytes of memory from a very small input, leading to crashes or unresponsiveness.

As a result, any application using DeepDiff versions 5.0.0 to before 8.6.2 that processes untrusted pickle data is at risk of being taken down by an attacker without requiring code execution privileges.

Useful 0 Not Useful 0

Compliance Impact

I don't know

Useful 0 Not Useful 0

Detection Guidance

[{'type': 'paragraph', 'content': 'This vulnerability manifests as a denial-of-service condition caused by excessive memory allocation during deserialization of untrusted pickle payloads in DeepDiff versions 5.0.0 to before 8.6.2.'}, {'type': 'paragraph', 'content': 'Detection can focus on monitoring applications that use DeepDiff for deserialization of pickle data, especially looking for unusually high memory usage or crashes related to out-of-memory errors.'}, {'type': 'paragraph', 'content': 'Since the vulnerability involves crafted pickle payloads causing large memory allocations, you can detect attempts by monitoring logs or network traffic for suspicious pickle data or by instrumenting the application to log or alert on large memory allocations during unpickling.'}, {'type': 'paragraph', 'content': 'Specific commands depend on your environment, but general approaches include:'}, {'type': 'list_item', 'content': 'Use system monitoring tools like `top`, `htop`, or `free -m` to observe memory usage spikes in processes running DeepDiff.'}, {'type': 'list_item', 'content': "Use Python debugging or logging to wrap or monitor calls to `pickle_load` or DeepDiff's delta application methods to detect unusually large constructor arguments."}, {'type': 'list_item', 'content': 'If you have access to network captures, use tools like `tcpdump` or `Wireshark` to filter for pickle payloads being transmitted, then analyze them for suspiciously small payloads that could cause large memory allocations.'}, {'type': 'list_item', 'content': 'Example Python snippet to detect large allocations during unpickling (conceptual):\n```python\nimport deepdiff\ntry:\n # Attempt to load pickle data\n deepdiff.pickle_load(untrusted_data)\nexcept MemoryError:\n print("Potential exploit attempt detected: memory exhaustion during unpickling")\n```'}] [1]

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation is to upgrade DeepDiff to version 8.6.2 or later, where the vulnerability has been patched.

The patch introduces a maximum allocation size limit of 128 MB for size-sensitive constructors like bytes() and bytearray() during unpickling, preventing excessive memory allocation.

If upgrading immediately is not possible, consider the following interim mitigations:

• Avoid deserializing pickle data from untrusted or unauthenticated sources.
• Implement application-level resource limits (e.g., using OS-level memory limits or Python resource module) to restrict the maximum memory usage of processes performing deserialization.
• Add additional validation or sandboxing around deserialization routines to detect and block unusually large constructor arguments.
• Monitor application logs and system metrics for signs of memory exhaustion or crashes related to deserialization.

Useful 0 Not Useful 0