Disclosure before giving the manufacturer time to respond should be reserved for extreme instances where an exploit is already being used in the wild or a high risk to many users.

Downloading .exe files without TLS is dumb but the threat model of this being used in an attack is pretty niche, since an attacker would need to spoof DNS to resolve a fake download URL. The only way this would happen would be if the ISP were compromised or the local machine is already compromised.

Thus I don’t think this was appropriate to disclose before giving the vendor time to respond. Exposing such a niche surface area for attacks greatly increases the likelihood of the vulnerability being used in targeted attacks while Gigabyte is busy trying to install Certbot.

However it wouldn’t be that difficult to actually execute this attack.

It’s not that difficult to spoof the DNS server or even DHCP responses on public wifi networks (or local LANs). Yes you can setup enterprise networks to detect or block that but plenty of people aren’t on enterprise networks: https://charlesreid1.com/wiki/Ettercap

It’s also easy to stand up wireless SSIDs of common public networks (eg “Apple Store”) and have devices preferentially connect to you if it happens to be earlier in the wifi network order list.

You can also steal all of a machines traffic by plugging a USB network adapter in: https://github.com/samyk/poisontap

Working SSL would prevent all of that auto running a downloaded executable by such a boot chain.