CWE-502: Deserialization of Untrusted Data

Serialization packages object-related data for storage or transfer, while deserialization extracts that data to reconstruct the original object. The weakness occurs when the product treats reconstructed data as valid or trustworthy without adequately checking its types, values, state, and possible behavior. An attacker may craft or alter the serialized representation to create unexpected objects, bypass normal accessor functions, invoke unintended methods, or trigger gadget chains available in libraries. The impact depends on the objects and methods that can be deserialized and how the application uses them, and the weakness can arise from a missing security tactic in architecture and design as well as from implementation decisions.

The defining behavior is accepting external serialized data and reconstructing internal objects or state without adequate validity assurance. The practice is also described as unmarshaling, pickling, or unpickling; in Python, pickle provides serialization and deserialization functionality. Deserialization can expose unexpected classes, methods, or library gadgets, allowing data to bypass safe accessors and alter application behavior. The record applies to Java, Ruby, PHP, Python, and JavaScript, and can occur in technology-specific contexts including ICS/OT and AI/ML.

• Integrity: Attackers may modify application data or produce an unexpected application state. Deserialized data or code may bypass intended accessor functions, and unexpected functions may be invoked.
• Availability: A parser or function that relies on a sentinel to determine when to terminate may be made not to terminate, causing CPU resource consumption and denial of service.
• Other impacts: Results vary with the objects and methods involved. Assuming that code in a deserialized object is valid can enable unauthorized actions, including gadget-chain behavior such as generating a shell.

• Authenticate serialized data: When available, use the language's signing or sealing features, such as an HMAC, to verify that serialized data has not been modified.
• Validate into a new object: During deserialization, populate a new object so the data passes through safe input validation and uses safe functions.
• Prevent deserialization where applicable: Explicitly define a final object to prevent deserialization.
• Protect fields: Make fields transient so time-dependent, environment-based, or sensitive values are not carried across serialization and deserialization; such fields become NULL after the round trip.
• Reduce gadget exposure: Avoid unnecessary types and deserialization gadgets, and allowlist only acceptable classes. This is not sufficient by itself because new gadgets are continually discovered.
• Protect data or code cryptographically: Cryptography can protect the data or code, but client-side cryptography remains bypassable if the client is compromised.
• Add an application firewall: A firewall can provide defense in depth, especially when the vulnerable code is controlled by a third party or cannot immediately be fixed. Its effectiveness is moderate and it may miss input vectors, be bypassed with specially malformed inputs, reject or alter legitimate requests, or require manual customization.

Automated static analysis, commonly called Static Application Security Testing (SAST), can identify some instances by analyzing source or compiled code without execution. It generally models data flow and control flow, then searches for potentially vulnerable patterns connecting input sources to sinks where data interacts with external components or lower layers. The method is rated highly effective, but it does not necessarily cover every case or behavior that appears only at runtime.

Representative examples in the record include CVE-2024-37052, where a crafted pickled object in an AI/ML model file leads to code execution; CVE-2024-37288, involving deserialization of untrusted YAML; and CVE-2024-9314, involving PHP object injection in a WordPress plugin. Other examples show PHP unserialize being used on untrusted input to modify application configuration or enable code execution (CVE-2013-1465, CVE-2012-3527, CVE-2012-0911), while Java libraries and Python scripts expose code-execution paths (CVE-2015-8103, CVE-2015-4852, CVE-2011-2520, CVE-2012-4406). The record also includes bypass through an assumed-trusted class (CVE-2019-12799) and browser execution of native methods through a crafted string passed to a JavaScript deserialization function (CVE-2003-0791). These are representative examples, not an exhaustive list of vulnerabilities.