It's well documented and very useful feature in aws and it also exists in gcloud, although gcloud documentation is not as good^1.
It only becomes a vulnerability if you don't read the documentation AND don't follow best practices^2.
I don't know if azure provides this feature.
^1 I use gcloud now and have used aws in the past.
^2 Don't run unknown code without proper sandboxing
Like Colin pointed out in the blog post, this completely subverts the permissions model in modern operating systems.
Calling this a vulnerability is akin to calling the existence of `rm` a vulnerability because it can delete files.
I allow usage patterns similar to what is being described, so it is a vulnerability in something, be it my fault or not.
169.254.0.0/16 is link-local range which you should be flitering along with publicly routable ip ranges that might be very upset if you access them like .mil reserved ip ranges. Go as far to also only allow DNS names instead of arbitrary ip, keeping in mind dns names may resolve to non publicly routable ranges or ranges you may not wish to access. These are all standard dangers of making queries on a user's behalf.
Good list of ipv4 ranges you should not allow: https://github.com/robertdavidgraham/masscan/blob/master/dat...