This rule is deprecated, and will eventually be removed.

Deserializing objects is security-sensitive. For example, it has led in the past to the following vulnerabilities:

- CVE-2017-17672: vBulletin: Unserialize PHP Code Execution
- CVE-2018-1000167: Jenkins Pipeline: arbitrary code execution vulnerability

Object deserialization from an untrusted source can lead to unexpected code execution. Deserialization takes a stream of bits and turns it into an object. If the stream contains the type of object you expect, all is well. But if you’re deserializing data coming from untrusted input, and an attacker has inserted some other type of object, you’re in trouble. Why? A known attack scenario involves the creation of a serialized PHP object with crafted attributes which will modify your application’s behavior. This attack relies on PHP magic methods like `__desctruct`, `__wakeup` or `__string`. The attacker doesn’t necessarily need the source code of the targeted application to exploit the vulnerability, he can also rely on the presence of open-source component and use tools to craft malicious payloads.

## Ask Yourself Whether

- an attacker could have tampered with the source provided to the deserialization function
- you are using an unsafe deserialization function

You are at risk if you answered yes to any of those questions.

## Recommended Secure Coding Practices

To prevent insecure deserialization, it is recommended to:

- Use safe libraries that do not allow code execution at deserialization.
- Not communicate with the outside world using serialized objects
- Limit access to the serialized source
  - if it is a file, restrict the access to it.
  - if it comes from the network, restrict who has access to the process, such as with a Firewall or by authenticating the sender first.

## See

- OWASP - Deserialization of untrusted data
- OWASP - Top 10 2017 Category A8 - Insecure Deserialization
- CWE - CWE-502 - Deserialization of Untrusted Data
- Derived from FindSecBugs rule OBJECT_DESERIALIZATION