My understanding from the write-up and example exploits of CVE-2015-4852 by Foxglove is that you need code which receives user-provided serialized objects and the Apache commons-collections present on the classpath to exploit.
With those two things, a request should be craft-able (although some may require trial and error / knowledge of system).
As I commented in this question about Spring Vulnerabilities, for a product to be vulnerable, it doesn't have to use the InvokerTransfomer directly. The problematic object is supplied by the exploit request. All the "vulnerable app" has to do is supply the commons-collections JAR and logic which invokes .readObject() on that user-supplied instance of InvokerTransformer.
Assuming that I'm understand this correctly... is it sufficient to evaluate a product (for which you have source) based on tracing backwards from where the ObjectInputStream.readObject() method is called and conclude that product is likely vulnerable if there's any way that the stream could contain objects provided by an external user?
Yes, if there is a path for untrusted data to reach a call to ObjectStream.readObject() and InvokerTransformer is on the classpath then the product or library is vulnerable.
If you have to accept untrusted data destined for deserialization then you may be able to block payloads that include InvokerTransformer. You'd have to roll your own serializable format parser or find a safe library that can do it.
Another mitigation is to unserialize in a separate classloader to which InvokerTransformer is inaccessible.
Far better yet - as @PhaedrusPhacdelm discovered - is whitelisting allowable classes for deserialization: http://fishbowl.pastiche.org/2015/11/09/java_serialization_bug/ http://www.ibm.com/developerworks/library/se-lookahead/