Yes,

That is exactly the reported issue here. PuTTY 0.68 through 0.73 allows the remote attacker to accurately determine whether or not the client has cached the host key. It looks like this works because PuTTY sends a different algorithm list depending on whether or not the key has been cached.

If the MiTM attacker sees the 'default algorithm list' it can be assumed that this is the first connection attempt and the attacker can substitute the server key with a compromised key.