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.

Expanded Definition

Unsafe deserialisation is the act of accepting serialized input from an untrusted source and reconstructing it into live objects without strict type, schema, and execution-path controls. In NHI and agentic systems, the risk is not only malformed data but hidden behaviour embedded in object graphs, gadget chains, or callable reconstruction. The boundary between “data” and “code” becomes especially important when request bodies, cookies, tokens, or session state are deserialized automatically. Definitions vary across vendors, but the practical security rule is consistent: if the sender is not fully trusted, deserialization must be treated as an attack surface, not a convenience feature. Guidance in NIST SP 800-63 Digital Identity Guidelines reinforces the need to bind identity handling to verified trust conditions, not opaque object restoration. The most common misapplication is allowing framework defaults to deserialize authentication material directly from cookies or API inputs, which occurs when developers confuse transport integrity with object safety.

For broader NHI governance context, see Ultimate Guide to NHIs.

Examples and Use Cases

Implementing deserialization safely often introduces friction, because rigid schemas and allowlists reduce developer convenience while sharply reducing exploitability.

• A Python API receives a pickled session blob and reconstructs it automatically. If the blob is attacker-controlled, a gadget chain can trigger code execution during load.
• A service account token is serialized into a cookie and later restored into an auth object. If integrity checks exist but the format permits callable restoration, the application may still execute unintended logic.
• An internal agent platform deserializes tool instructions from a message queue. If schema validation is weak, an attacker can smuggle fields that alter execution flow or privilege context.
• An orchestration system stores workflow state as objects in Redis and restores them on demand. Unsafe reconstruction can turn a simple state fetch into a remote attack path.

For NHI-focused governance patterns and lifecycle controls, the Ultimate Guide to NHIs is the clearest reference point. For identity assurance and verifier discipline, NIST SP 800-63 Digital Identity Guidelines provides the standards mindset that should shape any trust decision before object reconstruction occurs.

Why It Matters in NHI Security

Unsafe deserialisation matters because NHI systems are built around machine-to-machine trust, and attackers love trust shortcuts. When service accounts, API keys, or agent credentials are wrapped into objects and restored automatically, a single malformed payload can become privilege escalation, session hijack, or full remote code execution. This is particularly serious in environments already struggling with privilege sprawl: NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which means a successful deserialization flaw often lands on highly capable identities rather than low-value accounts. The risk is amplified when organisations assume authenticated input is automatically safe, or when they rely on signed data without constraining the deserializer itself. Secure design should prefer typed, versioned, non-executable formats, explicit validation, and strict separation between authentication state and application objects. Teams should also test whether a deserializer can instantiate unexpected classes, because that is where exploitability often begins. Organisations typically encounter the consequences only after a session compromise or agent takeover reveals that object restoration was quietly acting as an execution primitive, at which point unsafe deserialisation becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does an ephemeral credential become unsafe in agentic environments?
• How can organisations reduce unsafe AI outputs without over-restricting users?
• What breaks when prompt loading or deserialisation is not constrained?
• Who is accountable when an AI agent takes an unsafe action?