PHP Object Deserialization is the process of converting stored or transmitted serialized PHP data back into live objects. In security work, it matters because attacker-controlled object data can trigger magic methods, leading to code execution, file access, or other unexpected behaviour when unsafe deserialisation is used.
How PHP object deserialization works
PHP object deserialization turns serialized data back into live PHP objects with their properties, references and class metadata restored. That makes it a powerful runtime feature, but also one that can become dangerous when the input is not strictly trusted, because the application is no longer just reading data, it may be rehydrating executable object state.
In practice, the key security issue is that object construction is not always passive. When classes define magic methods such as __wakeup, __destruct or __toString, deserialisation can trigger code paths that were never meant to run on attacker-supplied input. A safe-looking data transform can therefore become an execution path if the application allows untrusted payloads into the deserialiser.
Why unsafe deserialisation becomes dangerous
The danger is not the format itself, but the trust boundary around it. If an attacker can influence the serialized payload, they may be able to steer object state, trigger gadget chains in the application or its libraries, and reach outcomes such as code execution, file access, data manipulation or denial of service. The severity depends on what classes are available and which methods they invoke when the object is restored.
This is why insecure deserialisation is usually discussed as an application security issue with broader blast radius. The weakness often appears in code that treats serialized blobs as convenient storage, session material or inter-service data without validating origin, integrity or class constraints. The result is not merely malformed input, but a control-flow problem where data becomes behaviour.
For a broader treatment of the attack pattern across languages and gadget-chain behaviour, see Insecure Deserialisation Guide.
Where PHP applications are exposed
Exposure usually comes from wherever the application accepts serialized values from a user, a browser, another service or a cached store without strong trust guarantees. Common entry points include cookies, session handlers, message queues, legacy integrations, file uploads and internal APIs that were designed for convenience rather than strict type handling.
The risk rises when the application relies on broad autoloading, includes third-party packages with rich object graphs, or exposes classes whose methods perform file operations, command execution, database access or network requests. Even when the application never intended to expose those capabilities, the deserialiser may still make them reachable through object state.
In PHP-heavy environments, the surrounding platform matters too. Hardening the runtime, reducing unnecessary classes and removing unused components all narrow the set of available gadgets. For deployment and runtime hardening context, PHP and WordPress Security Guide is useful background for reducing the attack surface around PHP applications.
Safer handling and defensive patterns
The safest pattern is to avoid deserialising untrusted input altogether. If serialised objects must be used, the application should constrain what can be rehydrated, prefer fixed schemas or simple data structures, and treat every deserialised value as untrusted until it has passed explicit validation. Integrity controls, strict type expectations and fail-closed parsing reduce the chance that arbitrary object graphs are restored.
Organisations should also review whether they are using deserialisation for problems that are better solved with JSON, explicit DTOs or other simpler formats. When deserialisation is unavoidable, reducing the available classes and eliminating dangerous side effects in object lifecycle methods materially lowers the chance that an attacker can turn data into behaviour.
For a structured view of secure loader settings, allowlists and fail-closed deserialisation patterns, the Secure Deserialisation Guide is the most direct reference.
Detection and compromise review after exploitation
Because exploitation often looks like ordinary parsing until the payload is processed, detection focuses on suspicious deserialisation events, unexpected object graphs, unusual method execution and downstream effects such as file writes, command invocation or anomalous access to application secrets. Logging the source, size and context of deserialised payloads can help distinguish normal application behaviour from abuse.
After a suspected incident, the review should assume the payload may have executed application logic rather than simply failed validation. That means checking for file-system changes, unexpected outbound connections, tampered configuration, altered sessions and any data that may have been read or written during object lifecycle hooks. If the application stores credentials, tokens or keys in reachable objects, those secrets should be treated as potentially exposed and rotated as part of the response.
For a defensive reference that ties together object injection, gadget chains and safe filtering approaches, the Insecure Deserialisation Guide provides the clearest conceptual bridge from mechanism to compromise review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | PHP deserialisation safety depends on rejecting attacker-controlled input before object rehydration. |
| V15 — Secure Coding and Architecture | Unsafe deserialisation is an application design flaw involving object lifecycle and trust boundaries. | |
| Recommendation — Enforce strict input handling before any deserialisation step. Remove deserialisation of untrusted data from application design. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Serialized payloads are untrusted inputs that must be validated before processing. |
| SI-7 — Software, Firmware, and Information Integrity | Integrity checks help ensure object state and payloads have not been tampered with. | |
| Recommendation — Validate serialized input before it reaches object construction or business logic. Apply integrity controls to data flows that feed deserialisation paths. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Deserialisation weaknesses are application-layer flaws addressed through secure development and testing. |
| Recommendation — Test application code for unsafe deserialisation and remove risky object handlers. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org