According to the published Proof of Concept code and the vulnerability description, the issue exists due to the improper filtering of the Java class properties during the HTTP input binding. For developers using Spring there is the possibility that an incoming HTTP request could be transformed directly to a Java Object.
This is possible due to some changes in Java 9, which could allow some potentially dangerous incoming HTTP parameters to be transmitted to the Spring runtime as the corresponding Object properties, which can lead to changing the parameters of internally running Objects. Java 9 added an extra getModule()
method, which could be used by an attacker to traverse the Object chaining path, providing another method to modify protected and potentially dangerous functions and properties.
The Proof of Concept code uses this issue, for example, to change the internal logger behavior, leading to arbitrary write in the publicly available directory. In this case a potential attacker can overwrite server files or write a backdoor (webshell file).
It should be noted that other Java web frameworks can be affected in this way, if their authors did not notice the changes in Java 9, and use the parameter binding in the same way.