The attack vector is some random part of the application server stack (JBoss) demarshalling and running commands on strings received directly from web clients.
A rather horrible practice to begin with. There's always so much that can go wrong when parsing tainted strings to native data structures, let alone to full objects using the builtin marshalling functions, they're not meant to be used on objects from untrusted sources at all!
Yep, same thing but with YAML deserialization. Deserialization vulnerabilities are common for Java, Python, Ruby, and PHP web apps, because deserializing an untrusted input is nearly akin to running eval() on an untrusted input.
1. Define exactly what the deserialization output should be.
2. Implement it that exactly that way.
Now it's simple. Does the definition in part (1) include execution of arbitrary commands?
A deserializer might be able to instantiate arbitrary classes, so any class with a constructor that could execute an arbitrary command makes the deserializer vulnerable.
Of course, the correct answer is not to use the deserializer that can instantiate arbitrary classes when you have a well-defined list of classes that can be instantiated.
A rather horrible practice to begin with. There's always so much that can go wrong when parsing tainted strings to native data structures, let alone to full objects using the builtin marshalling functions, they're not meant to be used on objects from untrusted sources at all!