Using HTTPS, the server is usually MORE vulnerable.
You still have the whole HTTP stack with its potential vulnerabilities exposed AND you now have all the TLS stack vulnerabilities for the attacker to pick from.
TLS vulnerabilities can be impressively bad - see e.g. the OpenSSL Hearthbleed.
On the other hand, HTTPS in some sense reduces the probability of the attack success by making it harder to obtain valid user credentials and/or to inject malicious code into the HTTP interaction.
(A lot of attacks are of "privilege escalation" type and require authentication, even if the authenticated user nominally has low privileges in the system.)
This is especially effective if the HTTPS server uses TLS authentication with client certificates. In this case, an attacker without a valid client certificate can only poke the TLS frontend. They will have to break the TLS code or obtain a valid cert + its private key by other means in order to get to the HTTP stack in the first place.
A well-maintained policy of issuing client certs only on hardware tokens may force the potential attacker well into the social engineering domain even if the system has gross HTTP or higher level vulnerabilities.