Deserialization Attack

The attack targets the deserialization process, where a byte stream is converted back into a live object. Attackers embed a malicious payload within the serialized data. When the AI framework (like PyTorch or TensorFlow) loads the model, the deserialization routine triggers arbitrary code execution, bypassing standard security controls. This is particularly dangerous because model files are often treated as inert data.

• Pickle Injection: The Python pickle module, widely used in PyTorch, can execute arbitrary code during unpickling.
• Keras Lambda Layers: Custom layers in HDF5 files can embed arbitrary functions that execute on load.
• ONNX Custom Ops: Malicious operators in ONNX graphs can trigger unsafe code execution.
• Java Deserialization: In Java-based ML serving systems, manipulating serialized Java objects can lead to remote code execution.

A successful deserialization attack grants the adversary full remote code execution on the inference server. This can lead to:

• Model Theft: Exfiltration of proprietary model weights.
• Data Breach: Access to sensitive training data or user inputs.
• Supply Chain Compromise: A backdoored model distributed via a public hub like Hugging Face can infect downstream consumer systems.
• System Takeover: Lateral movement within the enterprise network.

• Safetensors Adoption: Use the safetensors format instead of pickle; it is a pure data format with no code execution capability.
• Sandboxed Loading: Deserialize models in an isolated, air-gapped environment or a Trusted Execution Environment (TEE).
• Model Scanning: Scan all third-party models for malicious serialized objects before loading.
• Restrict Deserialization: Use safe, allow-listed deserializers that reject arbitrary object types.

Deserialization attacks are a direct threat to Model Provenance and the Algorithmic Supply Chain. Without a verifiable AI Bill of Materials (AIBOM) and strict Vendor Due Diligence, a compromised model can easily masquerade as a legitimate artifact. This attack vector underscores why Model Risk Tiering must include checks for unsafe serialization formats.

The fundamental process exploited in this attack. Serialization converts a complex object (like a model graph) into a byte stream for storage or transfer. Deserialization reconstructs the object from that stream. The vulnerability arises because the reconstruction process can trigger the execution of attacker-controlled code embedded in the stream, often through native __reduce__ (Python) or readObject (Java) methods.

Attackers rarely inject fully custom code directly. Instead, they craft a sequence of existing, benign classes within the application's libraries—called a gadget chain—that, when deserialized in a specific order, performs a malicious action. This is akin to ROP (Return-Oriented Programming) in memory exploits. A single vulnerable library in the AI serving stack is sufficient to provide the necessary gadgets.

The primary defense is to avoid native, object-graph deserialization of untrusted data entirely. Use purely data-centric formats that do not reconstruct arbitrary types:

• JSON/BSON: Parses only primitive data structures.
• Protobuf/Avro: Schema-defined, code-generated formats.
• ONNX: An interchange format for models that represents a static computation graph, not executable objects.
• Safetensors: A format specifically designed for safe, lazy tensor loading without code execution.

Before loading any model artifact, verify its provenance and integrity using cryptographic signatures. A typical workflow:

• The model creator generates a cryptographic hash (e.g., SHA-256) of the serialized file.
• The hash is signed with the creator's private key.
• The loading system verifies the signature against a trusted public key before deserialization.
• This prevents the execution of a model that has been tampered with in transit or at rest.

Execute the deserialization and model loading process within a heavily restricted, ephemeral environment. This limits the blast radius of a successful attack:

• gVisor/Firecracker: Use micro-VMs for strong, hardware-backed isolation.
• gRPC Sandboxing: Load the model in a separate, sandboxed server process with no network access.
• Seccomp/AppArmor: Apply strict kernel-level system call filters to the loading process.
• Capability Dropping: Run the loader with the absolute minimum Linux capabilities (e.g., CAP_SYS_ADMIN dropped).

Python's pickle module is the most common vector for ML deserialization attacks. Defensive measures include:

• Absolute Prohibition: Never use pickle.load() on untrusted data.
• pickletools.dis(): A static analysis tool to inspect a pickle stream's opcodes before execution, looking for suspicious REDUCE or GLOBAL instructions.
• Restricted Unpicklers: Custom Unpickler subclasses that override find_class to only allow a strict allowlist of safe, primitive modules (e.g., builtins, numpy).