These types of attacks are often a combination of things. At a very high level glance at the mentioned attack - it takes advantage of heap overflow in OpenSLP service that is running on port 427, then, after gaining execution ability, it uses another piece of code to encrypt matching files (ie vmdk).
This particular combination will not be possible against a vanilla PVE. There is no OpenSLP by default, nor are there any "vmdk" files...
Obviously this is "security through obscurity". Nothing stops an "enterprising" actor from adapting the code to attack PVE installation. And its trivial to change the list of targets to encrypt, ie add qcow.
But there is nothing special about PVE in that sense. If there is a vulnerability in standard Debian package that can be exploited remotely - any appliance based on Debian is exposed.
There are simple precautions that one may take to avoid the attack:
a) Dont expose PVE, or anything else really, to Internet unless you have an actual need and know what you are doing.
b) Block any non-essential ports via firewall
c) Restrict essential ports by firewall to a know "good" set
d) Use strong password and ssh keys
e) Keep your system up-to-date
If you must allow untrusted users in your environment, ie Cloud Service Provider, implement Multi-Tenancy at every possible level: Compute, Network and Storage.
Of course there are many more steps, but the above is a good start.
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox