AI agent testing exposes unsafe deserialization risks in ML systems

At a glance

What this is: Equixly says an AI agent found CVE-2026-0773 by probing ML APIs and turning unsafe deserialization into a remote code execution path.

Why it matters: It matters because ML pipelines often treat model artifacts, caches, and internal endpoints as data sources, even when they can execute code on load.

By the numbers:

• CVE-2026-0773 is a critical remote code execution vulnerability with a CVSS score of 9.8.

Context

Unsafe deserialization is the point at which data stops being inert and starts behaving like code. In ML systems, that boundary is easy to miss because model files, cached objects, and internal service payloads are often handled as trusted artefacts rather than executable inputs.

This article is really about governance failure in ML infrastructure: teams rely on the safety of the surrounding platform instead of classifying serialized objects as high-risk execution surfaces. The identity angle appears where service endpoints, pipelines, and model loaders accept machine-generated inputs without strong provenance or lifecycle controls.

Key questions

Q: What breaks when ML systems unpickle untrusted data?

A: The loader stops being a parser and becomes an execution path. If an attacker can influence the serialized object, the unpickling process can invoke code, reconstruct malicious state, or trigger downstream commands. In ML pipelines this usually means model files, caches, or internal APIs can turn into remote code execution vectors instead of safe data channels.

Q: Why do unsafe deserialization bugs in ML infrastructure create remote code execution risk?

A: Because the deserializer is allowed to rebuild Python objects, not just read bytes. When that object graph includes callable hooks or attacker-controlled instructions, the load step can execute code under the service’s privileges. In practice, the danger is highest where teams trust internal models, shared caches, or authenticated APIs too much.

Q: What are the signs that an ML API may be accepting dangerous serialized input?

A: Look for binary request bodies, unusual error messages such as unpickling failures, endpoints that accept model or processor registration objects, and services that load cached artefacts without validating provenance. Those signals suggest the API is reconstructing Python objects and may be one crafted payload away from execution.

Q: Should teams use pickle or cloudpickle for model loading in production?

A: Only when there is no viable alternative and the input source is fully controlled, signed, and tightly isolated. For most production uses, inert formats are safer because they separate data from executable behaviour. Where object serialisation remains necessary, load paths should be sandboxed and treated like privileged code.

Technical breakdown

Why pickle and cloudpickle can become execution paths

Pickle serialisation reconstructs Python objects during load, which means the loader can invoke functions, methods, and object hooks while rebuilding state. Cloudpickle extends that flexibility to lambdas, closures, and dynamically defined functions, which is useful for development but dangerous when the input source is untrusted. If an attacker can control the payload, deserialization can cross the line from parsing into code execution. That is why seemingly ordinary model files and cached objects can become a remote code execution vector in production ML systems.

Practical implication: Treat any pickle-based loader as an execution boundary and restrict where it can accept input from.

How AI agent testing found the vulnerability

Equixly describes an agent that mapped the API surface, sequenced requests in the right order, and reacted to error messages that revealed a pickle deserialization sink. The key difference from traditional scanning is contextual reasoning: the agent used response content, request structure, and endpoint behaviour to infer that malformed binary input was being unpickled. Once the sink was identified, payload generation could move from generic fuzzing to targeted exploitation validation. That is a useful reminder that modern testing needs to understand application state, not just signatures.

Practical implication: Add testing that validates deserialization behaviour in context, not just static endpoint or signature checks.

Why unsafe model files and caches are supply chain problems

In ML environments, model artefacts, cache files, and intermediate objects often travel through shared storage, CI/CD jobs, and internal APIs. If any one of those paths accepts a poisoned serialized object, the compromise can propagate into training, inference, or orchestration workflows. The issue is not limited to direct upload paths. It also includes trusted caches, shared volumes, and third-party model sources where a file appears harmless but contains executable object state. That makes deserialization a supply chain control problem as much as a coding flaw.

Practical implication: Classify model artefacts and cached objects as supply chain inputs and gate them with provenance and signing controls.

Threat narrative

Attacker objective: The objective is to convert trusted ML artefacts or internal endpoints into a code execution path that can expose credentials, alter pipeline behaviour, or compromise the underlying service.

1. Entry occurred when the AI agent probed an unauthenticated API endpoint that accepted binary input and returned an error revealing pickle handling.
2. Credential access was not the first objective here; the exploitation path instead leveraged deserialization logic to gain code execution on the target service.
3. Impact followed when the payload confirmed remote code execution, demonstrating that a malicious model or object file could execute arbitrary commands in the ML environment.

Breaches seen in the wild

• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Unsafe deserialization is an ML governance failure, not just a coding mistake. Teams often treat model artefacts as data because they sit inside AI workflows, but pickle-based formats can execute during load. That means the control problem starts with trust classification, provenance, and permitted loaders, not with later-stage detection. Practitioners should stop assuming that a model file is harmless because it came from an internal system.

AI-assisted testing changes how these flaws are found, not what the flaw is. Equixly’s example shows that agents can chain API discovery, stateful sequencing, and payload generation in ways that conventional scanners struggle to replicate. The implication for security programmes is that validation has to cover binary paths, error-driven inference, and deserialization sinks as first-class attack surfaces. Practitioners should build testing around behaviour, not file type labels.

Serialized artefacts now belong in the same risk class as executable software. The named concept here is deserialization trust gap: the dangerous assumption that an ML loader can safely reconstruct objects supplied by another system. Once that assumption is broken, model repositories, caches, and internal APIs all become delivery mechanisms for code execution. Practitioners should govern model artefacts as software supply chain inputs, not passive data.

What this signals

Deserialization trust gap: ML programmes now need a control that treats object loading as an execution decision, not a format choice. When model repositories, caches, and internal APIs can all carry code-bearing objects, governance has to focus on provenance, allowed loaders, and where reconstruction is permitted.

Unsafe deserialization is especially relevant to agentic testing because AI systems can discover stateful paths that static tools miss. The practical shift is toward testing deserialization behaviour under real API conditions, then restricting the blast radius of any service that must still reconstruct objects.

For practitioners

• Classify pickle-based loaders as execution boundaries Inventory every place your ML stack uses pickle, cloudpickle, torch.load, joblib, or similar object reconstruction and treat each as a code-execution surface.
• Move model distribution to inert formats Use safetensors, ONNX, JSON, YAML, or protocol buffers where the use case allows, and reserve object serialisation only for tightly controlled internal workflows.
• Gate serialized artefacts with provenance and signing Require signed model files, verify source integrity before load, and reject artefacts arriving through shared caches, CI jobs, or third-party model repositories.
• Test internal ML APIs for deserialization sinks Add security tests that send malformed binary inputs, inspect error messages, and validate whether any endpoint or worker unpickles attacker-controlled data.

Key takeaways

• Unsafe deserialization turns ML loaders into execution boundaries, which is why model artefacts and cached objects must be governed like code.
• Equixly’s example shows that AI-assisted testing can expose binary deserialization paths that conventional scanners often overlook.
• The control that matters most is not just detection after the fact, but limiting where serialized objects can come from and how they are loaded.

Key terms

• Unsafe Deserialisation: Unsafe deserialisation happens when an application turns untrusted serialized data back into objects without strict validation. In Python, this can become code execution if the format supports callable reconstruction or hidden execution paths. Authentication code should avoid it entirely when processing cookies, sessions, or request data.
• Pickle: Pickle is a Python serialisation format that stores and recreates complex objects, including behaviour as well as data. Its convenience is also its weakness, because unpickling can invoke object hooks and callable paths that become dangerous when the source is attacker-controlled.
• Cloudpickle: Cloudpickle is a Python serialization library that can handle dynamic objects such as lambdas, closures, and functions defined at runtime. That flexibility is useful for machine learning workflows, but it also expands the attack surface because the serialized object may contain executable behaviour, not just data.
• Model Supply Chain: The model supply chain is the set of external and internal components that shape an LLM application, including data sources, plugins, embeddings, APIs, and third-party services. Security teams must govern it as a trust surface because compromise can alter behaviour without changing the core model.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern control design. It helps practitioners align identity controls with the broader security decisions their programmes now depend on.