`metadataupload` takes a .zip file as POST input. This endpoint can be trivially reached on any SAP instance without authentication. The .zip file can contain a .properties file, which is deserialized into a java.util.Properties instance.

Since they're using Java deserialization, it is possible to deserialize arbitrary objects. The actual exploit uses a payload generated by ysoserial (https://github.com/frohoff/ysoserial) to either execute a command directly or drop a file on the filesystem. The basic idea behind a deserialization attack is to construct an object graph such that, when deserialized, functions that run normally as part of the deserialization process end up calling arbitrary code.

Deserialization attacks are well-known in the Java world, and are very common thanks to the fact that the serializer is both easy to use and baked into the language. With a large enough codebase (or the right dependencies) you're practically guaranteed to have enough serializable types to string together an RCE.

As an example, one of the classes used in this exploit is org.apache.xalan.xsltc.trax.TemplatesImpl (https://xalan.apache.org/xalan-j/apidocs/org/apache/xalan/xs...). This class contains a serializable array of Java .class bytecodes which will be dynamically loaded if the `newTransformer` method is called; note that merely loading a Java `.class` will be enough to run arbitrary code via static constructors. Other serializable classes are used to get the `newTransformer` method to be called on the object during deserialization.

The OP post is full of nonsensical and outright incorrect fluff. This is a straightforward deserialization-to-RCE bug; the RCE is what's being used to upload arbitrary files.