Learn the vocabulary of the risks in reconstructing objects directly from untrusted, attacker-controlled serialized data.
0 / 5 completed
1 / 5
A teammate explains that an application reconstructs objects directly from untrusted, attacker-controlled serialized data, and a crafted payload can trigger unintended method calls or arbitrary code execution during that reconstruction. What vulnerability is being described?
Insecure deserialization is exactly this: an application reconstructs objects directly from untrusted, attacker-controlled serialized data, and because deserialization can invoke constructors, setters, or other methods during reconstruction, a crafted payload can trigger unintended method calls or even arbitrary code execution. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This reconstruct-untrusted-data-without-validation approach is exactly why deserializing attacker-controlled input is treated as a critical vulnerability class.
2 / 5
During a security review, the team discovers an API endpoint deserializes a binary blob directly from an HTTP request body into native objects, using a general-purpose deserializer capable of invoking arbitrary classes' constructors. Which risk does this represent?
This represents an insecure-deserialization vulnerability, since a crafted binary blob could invoke unintended constructors or methods during reconstruction, potentially leading to code execution. Validating the blob against an allow-list of expected types before deserializing would instead constrain which classes could ever be instantiated, closing off that attack surface. This deserialize-with-a-general-purpose-deserializer behavior is exactly why unrestricted deserialization of attacker-controlled input is flagged as dangerous.
3 / 5
In a code review, a dev notices an endpoint deserializes a user-supplied payload using a general-purpose deserializer with no restriction on which classes can be instantiated during reconstruction. What does this represent?
This is an insecure-deserialization risk, since an unrestricted deserializer lets a crafted payload instantiate arbitrary classes, potentially triggering unintended code execution. A cache eviction policy is an unrelated concept about discarded cache entries. This unrestricted-class-instantiation pattern is exactly the kind of vulnerability a reviewer flags once the payload originates from an untrusted client.
4 / 5
An incident report shows an attacker achieved remote code execution by sending a crafted serialized payload to an endpoint that deserialized it using a general-purpose deserializer with no class restrictions. What practice would prevent this?
Restricting deserialization to an explicit allow-list of expected, safe types ensures a crafted payload can never instantiate an unexpected class during reconstruction. Continuing to deserialize incoming payloads with the unrestricted general-purpose deserializer regardless of what classes an attacker's payload might reference is exactly what let the attacker achieve remote code execution in this incident. This allow-list-restricted-deserialization approach is the standard fix once unrestricted deserialization of untrusted input is confirmed to be exploitable.
5 / 5
During a PR review, a teammate asks why the team insists on restricting deserialization to an allow-list of types instead of just using the general-purpose deserializer that already ships with the language's standard library. What is the reasoning?
Restricting deserialization to an allow-list trades a small amount of upfront configuration for closing off arbitrary class instantiation, while the unrestricted general-purpose deserializer is convenient but lets a crafted payload instantiate any class reachable on the classpath. This is exactly why allow-list-restricted deserialization is mandated for untrusted input, while the unrestricted deserializer remains acceptable only for data that is fully trusted, such as an application's own internally generated cache files.