CWE-502: Deserialization of Untrusted Data

Description:
The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.

Affected languages: Java, Ruby, PHP, Python, JavaScript
Affected technologies: Not Technology-Specific, ICS/OT, AI/ML
Parent weaknesses: CWE-913, CWE-913

Consequences:
  - Integrity: Modify Application Data
  - Availability: DoS: Resource Consumption (CPU)
  - Other: Varies by Context

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Architecture and Design] If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
  - [Implementation] When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
  - [Implementation] Explicitly define a final object() to prevent deserialization.
  - [Architecture and Design] Make fields transient to protect them from deserialization. 
                   An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variable

Demonstrative examples:
This code snippet deserializes an object from a file and uses it as a UI button:
This code does not attempt to verify the source or contents of the file before deserializing it. An attacker may be able to replace the intended file with a file that contains arbitrary malicious code which will be executed when the button is pressed.
try { File file = new File("object.obj"); ObjectInputStream in = new ObjectInputStream(new FileInputStream(file)); javax.swing.JButton button = (javax.swing.JButton) in.readObject(); in.close(); }
private final void readObject(ObjectInputStream in) throws java.io.IOException { throw new java.io.IOException("Cannot be deserialized"); }

In Python, the Pickle library handles the serialization and deserialization processes. In this example derived from [REF-467], the code receives and parses data, and afterwards tries to authenticate a user based on validating a token.
Unfortunately, the code does not verify that the incoming data is legitimate. An attacker can construct a illegitimate, serialized object "AuthToken" that instantiates one of Python's subprocesses to execute arbitrary commands. For instance,the attacker could construct a pickle that leverages Python's subprocess module, which spawns new processes and includes a number of arguments for various uses. Since Pickle allows objects to define the process for how they should be unpickled, the attacker can direct the unpickle process to call Popen in the subprocess mo

Real-world examples:
  - CVE-2024-37052: insecure deserialization in platform for managing AI/ML applications and models allows code execution via a crafted pickled object in a model file
  - CVE-2024-37288: deserialization of untrusted YAML data in dashboard for data query and visualization of Elasticsearch data
  - CVE-2024-9314: PHP object injection in WordPress plugin for AI-based SEO
  - CVE-2019-12799: chain: bypass of untrusted deserialization issue (CWE-502) by using an assumed-trusted class (CWE-183)
  - CVE-2015-8103: Deserialization issue in commonly-used Java library allows remote execution.