So the good news is VMware has a built in updater, and even better the server it uses to query for information is SSL/TLS enabled. The bad news is they are using Akamai with an insecure configuration: A quick note: Akamai is a huge content delivery network (CDN) used by many vendors to deliver content and software updates to end customers. Some pretty insecure configurations of SSL and TLS are supported by Akamai for the simple fact that there is still a lot of old software/clients out there, which Akamai’s customers want to support. As you can see here if you query https://www.ssllabs.com/ssltest/analyze.html?d=softwareupdate.vmware.com they use an Akamai certificate: Nothing wrong so far, but when you look at the versions of the SSL protocol that are supported they have left SSL 2.0 enabled, and they have also left weak ciphers including several 40 bit ones enabled: This makes an SSL downgrade attack trivial for an attacker as 40 bit keys can be broken in near real time now with even a remotely powerful computer that has a GPU. Using this an attacker can man in the middle your upgrade session and tell the client no updates are available (forcing you to remain on an older version with security issues), or potentially send you a malicious update. I haven’t looked at the guts of the VMware updater, for all I know they may use additional protections like secure signing of the update software itself, but let’s hope they do, because the communication channels it is sent over are not very secure. The good news is that fixing this is easy, VMware just needs to make sure their updater software supports TLS and secure ciphers (which if they’re using an even moderately up to date library won’t be a problem), and they need to update their Akamai configuration to exclude SSL 2.0 and the weak ciphers.