Skip to content

Insecure Object Serialization

Insecure Object Serialization


The application uses an insecure deserialization scheme from untrusted data.

Insecure object deserialization may result in

  • Arbitrary remote code execution
  • Modification of the application logic
  • Data tampering, such as bypassing access control

The exploitation of deserialization vulnerabilities is difficult due to the absence of off-the-shelf exploits and the need to tweak them for the targeted exploit.


To prevent object serialization vulnerabilities, the application must either:

  • Accept serialized objects from trusted sources only
  • Use serialization primitive data types only

If these measures are not possible, consider the following:

  • Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering.
  • Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. However, bypasses to this technique have been demonstrated, so reliance solely on this is not advisable.
  • Isolating and running code that deserializes in low privilege environments when possible.
  • Logging deserialization exceptions and failures, such as where the incoming type is not the expected type or the deserialization throws exceptions.
  • Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
  • Monitoring deserialization, alerting if a user deserializes constantly.


  • CWE_TOP_25:
    • CWE_502
    • V5_5_1
    • V5_5_3
    • V1_5_2
    • V5_5_1
    • V5_5_3
    • V1_5_2
    • V5_5_1
    • V5_5_3
    • REQ_2_2
    • REQ_6_2
    • REQ_6_3
    • REQ_6_4
    • REQ_11_3