Correct. Sadly the issue is that the cloud provider installed an agent that only blocks requests if the authentication header does not contain correct authentication.

If you remove the authentication header, that check never fires, and it considers you authenticated. Then it proceeds to let you run any command.

Now the point is, anyone who can send you messages can strip the authentication header, so anyone who can send you messages can execute arbitrary commands.

I don't think that's the threat model here - this is more a lateral movement vector for an attacker that's able to get inside your service network perimeter.

The threat is not the cloud provider and this has nothing to do with physical access.

The software vulnerability can be exploited by anyone with network access to the machine.

The thread model isn't the cloud provider, it's anyone who can spoof the IP of your cloud provider's metadata service CIDR block. These tend to be link-local IPs, so it's common for the cloud boundary firewall itself to block anything incoming from that block, so the attacker would need to already in the perimeter, but it isn't exactly hard to get inside the data center just by being another tenant. This is one reason why it's common to block at the host level any packets with a src IP in the metadata service's CIDR block, just in case. You give up certain forms of remote management capabilities, but that is often worth it not to open up back doors developers are rarely even aware of.