Seeking any example of exploitable unsafe deserialiazation where the serialized format is json and not some binary format.

Even better would be an example where calling a Java constructor of an arbitrary class(in some common library) is sufficient to do something malicious, and not rely on vulnerable readResolve, readObject or such specific to Java Serialization.

  • 2
    I googled your title and got this as the top hit: owasp.org/images/d/d7/…
    – schroeder
    Commented Jun 11, 2019 at 9:19
  • Any specific reason you mention Java? JSON deserialization libraries are available for all major languages, and languages like C (with no variable-length string type) are naturally more vulnerable.
    – MSalters
    Commented Jun 11, 2019 at 9:31
  • 1
    This is embarrassing, I obviously googled a bit, but only when writing the question did a formalize better what I was looking for, mostly I wanted to refute claim that the issue is only with binary formats like Java serialization and python pickles. At a glance the link answers at least my first part, but using setters and not using non default constructors as in my second part.
    – Meir Maor
    Commented Jun 11, 2019 at 9:33
  • Is not clear what you asking for, looks like a programing question more than security question
    – camp0
    Commented Jun 11, 2019 at 10:38


You must log in to answer this question.

Browse other questions tagged .