As stated in RPyC documentation, new-style (since RPyC 3.00) RPyC servers aren't meant to allow clients complete control over the server:
- https://rpyc.readthedocs.io/en/latest/tutorial/tut3.html, The new model is service oriented: services provide a way to expose a well-defined set of capabilities to the other party...
- https://rpyc.readthedocs.io/en/latest/docs/security.html, Unlike version 2.6, RPyC no longer makes use of insecure protocols like pickle,...
And the previous case of such bug has been registered as the critical CVE-2019-16328 through which arbitrary code execution with default configuration settings is possible. This vulnerability achieves the same goal through the numpy array deserialization mechanism added to resolve Issue #236, "Trouble accessing remote numpy objects" (tomerfiliba-org/rpyc#236), which seems to have slipped under the radar and