A deserialisation flaw is a weakness that lets untrusted data be converted back into objects in a way that can trigger unsafe behaviour, including code execution. In machine learning pipelines, this can turn a model load operation into an attack path if the artifact has been tampered with.
What a deserialisation flaw actually changes
A deserialisation flaw turns a routine data-handling step into an execution boundary problem. Instead of treating input as inert structure, the application accepts data that can influence object creation, class selection, method calls, or other unsafe behaviours during reconstruction.
That matters because deserialisation is often used in trust-heavy places, such as session state, cache payloads, message queues, APIs, and model or artifact loading. If the input can be altered by an attacker, the flaw is not just a parsing bug, it is a path for untrusted data to gain influence over program logic.
In practice, the danger ranges from denial of service and state corruption to remote code execution, depending on the language runtime, object graph, gadget availability, and the safety of the deserialiser. A secure design assumes deserialised data is hostile unless the format, schema, and object types are tightly constrained.
Why deserialisation flaws become attack paths
Attackers look for deserialisation flaws because they often provide high leverage from a small amount of tampered input. If the application accepts attacker-controlled payloads, the exploit may occur before normal business logic, input validation, or authorization checks have a chance to run.
That creates a useful entry point for code execution, privilege abuse, or deeper compromise, especially when the deserialised object can trigger constructors, callbacks, polymorphic type resolution, or implicit method execution. In machine learning and MLOps pipelines, a poisoned artifact can turn model loading into a compromise event rather than a passive import step.
The risk is amplified when deserialisation is hidden inside libraries or frameworks, because teams may assume the unsafe behaviour is the framework’s responsibility rather than part of their own trust boundary.
Where deserialisation flaws show up most often
They are most common where applications trade convenience for implicit trust. Examples include Java object streams, .NET binary serializers, Python pickling patterns, YAML or XML loaders with dangerous type resolution, and custom application formats that reconstruct rich objects from untrusted input.
They also appear in distributed systems where one component assumes another has already sanitised or signed the payload. Once the payload crosses service boundaries, any missing authenticity check or integrity guarantee can make deserialisation the weak point that converts a malformed blob into an execution event.
In modern supply chains, the same concern extends to software artifacts, configuration bundles, and ML model files. If the artifact is not provenance-checked, a load step can become a code path rather than a simple read operation.
How to think about safer handling
The defensive goal is to reduce what the runtime is allowed to reconstruct and to make trust explicit. Constrain accepted formats, avoid generic object deserialisation for untrusted data, and prefer simple data structures over rich object graphs whenever possible.
Integrity and provenance controls matter just as much as parser hardening, because a deserialiser can only safely consume data that has been authenticated and verified before it reaches the load path. For artifact-heavy workflows, SLSA is useful for thinking about provenance and integrity across the build and delivery chain, while OWASP API Security Top 10 helps frame how untrusted payloads can cross into backend processing.
Where teams need implementation guidance around input handling, the OWASP Cheat Sheet Series is a practical companion for safe data handling patterns, especially when deserialisation sits near authentication, sessions, or object lifecycle logic.
Risk and Threat Considerations
Deserialisation flaws are high-impact because they can convert a data integrity issue into an execution issue. Once an attacker can influence object construction or type resolution, the exposed surface may include remote code execution, denial of service, or stealthy state manipulation before normal controls engage.
Failure mechanism: Untrusted input reaches a deserialiser that accepts dangerous object types, gadget chains, or unsafe constructors, allowing attacker-controlled data to trigger unintended behaviour during reconstruction.
Impact: The result can include code execution, privilege abuse, persistence in application workflows, corrupted state, or compromise of downstream systems that trust the loaded object or artifact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Artifact and Secret Integrity | Deserialised model or artifact loading is an integrity-sensitive trust boundary. |
| Recommendation — Verify artifact integrity and provenance before loading any external serialized object or model. | ||
| CIS Controls v8 | CIS 16 — Application Software Security | Safe handling of untrusted input and insecure object loading fits application security hardening. |
| CIS 8 — Audit Log Management | Deserialisation abuse often needs logging and detection around suspicious load events. | |
| Recommendation — Review code paths that deserialize untrusted input and remove unsafe object-loading patterns. Log and alert on unexpected deserialisation failures, type mismatches, and anomalous load activity. | ||
Practitioner Guidance
What to watch for: Treat any generic object-loading path, especially one that handles external input, as a security-sensitive boundary. The strongest warning sign is convenience-driven use of a deserialiser that was chosen because it is easy, not because it is safe for untrusted data.
Governance implication: Ownership should sit with the team that controls the trust boundary, not only with the library maintainer or platform team. If a component accepts serialized input, the team should be able to explain why that format is safe, what types are permitted, and what verifies the artifact before load time.
Practitioner takeaway: If the payload cannot be fully trusted, do not let the runtime reconstruct arbitrary objects from it. Restrict the format, validate provenance, and keep deserialisation as boring as possible.
Related resources from NHI Mgmt Group
- How should teams respond to a local Linux privilege escalation flaw in shared environments?
- What is the difference between patching a host and governing the blast radius of a kernel flaw?
- What should teams do first after an AI agent privilege escalation flaw is found?
- What should teams do first after an OpenSSH certificate flaw is disclosed?
