Unauthorized access to our Phoenix server: November 2026 incident report 

Updated November 10, 16:03 UTC: LiteSpeed released the fix in LiteSpeed Web Server 6.3.7 Build 9, and it’s now installed on all our shared hosting servers. We’ve updated this post accordingly.

On November 9, 2026, we detected unauthorized access to one of our shared hosting servers in Phoenix, United States. The attacker exploited a previously unknown (zero-day) vulnerability in one of our vendors, LiteSpeed Web Server. We mitigated the issue on our shared hosting servers and worked with LiteSpeed to develop a permanent fix, which is now installed on all our shared hosting servers. 

Below, we explain what happened and how we responded.

In short:

• What happened: an attacker exploited a vulnerability in a customer’s website to get onto the server website was hosted, then used another previously unknown vulnerability in LiteSpeed Web Server, the software we use to serve websites, to break out of that website’s isolated environment.
• Who is affected: customers on one of the more than 5,000 servers we operate. The attacker ran code or read credentials on about 400 accounts.
• What we did: moved every account and website to other servers, restored affected websites from backups taken before the attack, and closed each path the attacker used. On November 10, when LiteSpeed released a fix, we deployed it on all our shared hosting servers.

What happened

On November 8, our security team’s monitoring tool flagged suspicious activity on the server. The investigation found that an attacker had first entered on November 5 through a vulnerable content management system on a customer website.

From there, it took three days for the attacker to find and exploit a new vulnerability in LiteSpeed Web Server. It allowed code from one website to bypass the isolation between accounts provided by CloudLinux CageFS, eventually leading to root-level access on the server.

The attacker ran code or read credentials on about 400 accounts, including database credentials and access tokens. We found no evidence that the attacker compromised our internal management systems, our backup system, or the systems that handle logins to Hostinger accounts, and no evidence that any backups were decrypted.

What we did

Because the attacker’s code ran as the shared web server user, their activity blended in with normal server traffic until our security monitoring systems identified it. We declared an incident at 12:26 UTC on November 9. We removed the attacker’s access, rotated internal credentials, and preserved evidence for forensic analysis. From 13:30 UTC, we moved accounts to other servers and restored affected websites from backups taken before the attack. The original server is offline and held for investigation.

We emailed affected customers individually and notified the competent authority about the incident.

In parallel, we worked directly with LiteSpeed to fix the vulnerability. On November 10, LiteSpeed released the fix in 6.3.7 Build 9, and by 16:03 UTC, it was installed on all our shared hosting servers.

What’s next

The configuration changes we made during the response stay in place as an extra layer of protection. Our investigation is ongoing, and we’ll update this post with any new findings.

If you have questions, our Customer Success team is available 24/7 through the Hostinger dashboard, and you can report security concerns to security@hostinger.com.