From a safety point of view the JVM essentially only guarantees type and memory safety. To that end it is just a mechanism to provide the same guarantees any ot

From a safety point of view the JVM essentially only guarantees type and memory safety. To that end it is just a mechanism to provide the same guarantees any other safe language does (Haskell, c#, rust, etc). So what this means is an attacker theoretically cannot corrupt your program while it is running. If your program has a path where it can do dangerous stuff, and an attacker can make your program do it, then it will. The problem hit here is that Java (and many languages of the era) provide a built in object serialiAtion and deserialization mechanism in which the data to be deserialized specifies what object is being instantiated (at one point I think you could literally include Java classes themselves, but I don’t know if that’s relevant here). Now imagine you had a CommandExecutor class the runs a binary when you construct it: Java’s deserializer will happily build it, even if you never intended that to happen. Modern deserialization libraries require you to specify at each step exactly what you intend to deserialze. Older libraries with bincompat issues takes steps to try and limit the default behavior (objc has NSSecureCoding), which is basically a flag on the class saying “it’s reasonable to load me in an untrusted context” - not the best but better than nothing.