I think you're being downvoted because there are two readings of your first question and reading the whole paragraph is needed to understand that the flippant reading "Psh, you say this is happening to you but I don't believe you, show me some evidence" is wrong and the humble reading "hey, how can I know that this is happening to me -- is it in the log files?" is correct. (It could also be that you're confessing ignorance even though you're also claiming certification though.)

The easiest MITM attacks for a civilian to perform involve a wireless router that traffic is routed over, with mildly more complicated but similar setups near a server -- say an untrusted server farm for example, or a malicious employee at a self-hosted location. More complicated attacks require messing with DNS so that people wanting to connect to that host instead connect to you; and really big entities like governments or advertising-hungry service providers could of course try to set something bigger up that affects more people.

The basic necessity is that the MITM computer needs to have an IP address, because the premise of MITM is, "you issue a request to connect securely to server IP 123.45.67.89, but you send your packets through me, and I have access to some IP 98.76.54.32. So now I intercept them rather than forwarding them on, and I connect securely to 123.45.67.89 myself, as well as to you. Now everything you try to send to them gets through, and its response gets back to you, but not before I intercept it and decrypt it and store it for later retrieval.

So the simplest way to do something like SSH is to imagine that I ask for your public key, you give it to me, I encrypt a shared private key with your public key, I send it to you, you decrypt it, and we use this private key for the rest of our communication. (That's not what SSH does, SSH does Diffie-Hellman, but similar reasoning applies.)

A MITM attack is then, you ask for the public key, I make a public/private key pair, I send you that public key, I ask for the remote server's private key for myself. You send me a private key, I send the remote server a different private key, and when you send something to the server, I now decrypt what you sent me, then encrypt it and send to the server.

Your main means of security in this scenario is actually 100% the same as your main means of security in SSH, it is that you trust that the private key of the server does not change very often. Therefore when you connect, you store the first public key you ever see; then each time you connect, you double-check it's the same or else you shout at the user "HEY! someone could be overhearing your data! Are you SURE you want to connect still?"

What's at issue in the article is that this crucial step was totally ignored by Hashicorp, it was brought to their attention and they just missed it.