Deserialization remote code execution is when loading a serialized object triggers unintended code execution. In ML supply chains, this is a major risk because formats like pickle can call functions during load time. The danger is not just malformed data, but attacker-controlled behavior hidden inside the artifact.
Expanded Definition
Deserialization remote code execution is a code-execution flaw, not simply a data-validation problem. It happens when a program restores an object from a serialized format and the load process itself can invoke methods, constructors, or other executable hooks that the attacker influences. In practice, the boundary is the trust decision around the artifact: if the serializer can represent behaviour as well as data, the loader must treat the input as potentially active.
This term is most often discussed in software supply chains, application runtimes, and machine learning workflows where pickle-like formats, model bundles, plugins, or cached objects are loaded automatically. The same pattern can appear in backend services that accept opaque objects from queues, APIs, or storage. The common misunderstanding is to assume deserialization is safe once the bytes are authenticated. Integrity helps, but it does not remove the risk if the format itself can express executable behaviour.
Where consensus is strongest, defenders should treat unsafe deserialization as a trusted-code boundary failure. Where practices differ, the exact risk depends on the format, the loader, and whether object construction is constrained or fully arbitrary. A standards-based identity control reference is only incidental here, so this term is better understood through software trust and execution boundaries than through identity governance.
Examples and Use Cases
Unsafe deserialization shows up in a few recurring environments:
- Python applications that unpickle objects from shared storage, where a crafted object can trigger code paths during load.
- Machine learning pipelines that deserialize model artifacts or feature caches from external sources without strict format allowlisting.
- Message-driven systems that treat serialized payloads as trusted internal data after they cross a queue, broker, or object store boundary.
- Administrative tooling that restores session state, job state, or plugin state from files that were not produced entirely within the same trust domain.
The trade-off is convenience versus control. Rich serialization formats can preserve application state efficiently, but they also expand the execution surface if the loader accepts more object behaviour than the application truly needs. A safer pattern is to prefer data-only representations when code execution is unnecessary, and to keep opaque artifacts out of automatic load paths unless their provenance is tightly controlled.
In ML environments, this issue is especially important because model portability can mask the difference between data and executable behavior. A file that looks like a model artifact may still carry load-time logic if the format allows it.
Security Implications
The main security consequence is that an attacker can turn a routine load operation into initial execution inside a process that was expected to only read data. That can lead to application compromise, command execution, secret theft, lateral movement, or tampering with downstream outputs. The blast radius is often larger than the single file because deserialization frequently occurs in build jobs, workers, schedulers, or automation services with broad access.
Failure usually occurs when one of three assumptions is wrong: the source is not actually trusted, the format is not data-only, or the loader executes helper logic before any meaningful validation. Once that happens, malicious behavior can be embedded in an artifact that may look ordinary in logs, scans, or storage metadata. That makes detection harder than with a simple malicious binary.
A practical observation from NHI Management Group is that these incidents are often missed when teams focus on file reputation alone. The real control problem is whether the runtime ever treats inbound objects as executable structure. When it does, the security boundary has already been crossed.
Domain and Governance Relevance
In software governance, deserialization RCE is a trust-boundary issue: the organisation is deciding which inputs may influence live execution and which must remain inert data. That matters for secure SDLC, artifact handling, and supply-chain assurance because the same code path can be safe in one context and dangerous in another depending on who produced the object and how it is restored.
This term becomes even more material in ML and automation stacks because serialized artifacts may move across teams, vendors, environments, and build stages. If the organisation uses non-human identities to fetch, sign, promote, or restore those artifacts, then ownership and provenance controls become part of the attack surface. The security question is not only whether the artifact is authentic, but whether the consuming system has any business need to execute load-time behavior at all.
For identity-heavy pipelines, the governance lesson is to separate artifact trust from execution privilege. A system that can download a model or cache object should not automatically be allowed to interpret embedded behavior as code unless that is a deliberate and reviewed design choice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Deserialization RCE often ends in attacker-controlled execution. |
| Recommendation — Map load-time execution to T1059 and monitor for unexpected interpreter invocation. | ||
| CIS Controls v8 | 16 — Application Software Security | Unsafe deserialization is a software trust-boundary flaw in applications. |
| Recommendation — Use Control 16 to prohibit unsafe object loading and restrict executable formats. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Serialized artifacts need protection because data can carry executable behavior. |
| PR.AC — Identity Management, Authentication, and Access Control | Execution from loaded objects often succeeds because loaders are overly trusted. | |
| DE.CM — Security Continuous Monitoring | Unsafe deserialization is often visible only through runtime behavior and telemetry. | |
| Recommendation — Apply PR.DS to treat untrusted serialized objects as active attack surface. Use PR.AC to limit which services can fetch, restore, and execute artifacts. Instrument DE.CM to detect unexpected deserialization paths and abnormal process starts. | ||
Related resources from NHI Mgmt Group
- What is the difference between prompt injection and LLM remote code execution?
- Who is accountable when an exposed backup service is used for remote code execution?
- How should teams respond when Apache HTTP Server has a remote code execution CVE?
- How should security teams contain remote code execution in workload environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
