A website can be perfectly maintained, have a strong password and still be caught up in someone else’s security incident.
That is the uncomfortable lesson from a LiteSpeed Web Server zero-day exploited on a Hostinger shared hosting server in Brazil on 16 September 2026. One vulnerable component allowed an attacker to break through the boundaries between hosting accounts, gain root-level access and deploy a webshell across hundreds of websites.
Hostinger says 430 accounts were affected, with unauthorised commands detected on 10 of them. Other reporting put the figures at 399 accounts and 11 affected by commands. Either way, the message for growing businesses is the same: shared hosting means sharing more than a monthly bill.
It means sharing the underlying server, software and risk.
The case study: what happened?
At 16:08 UTC on 16 September, Hostinger’s monitoring systems flagged unusual activity on a shared hosting server in its Brazil data centre.
The attacker had exploited a previously unknown critical vulnerability in LiteSpeed Web Server versions before 6.3.7 Build 2. This type of vulnerability is known as a zero-day because the vendor and administrators had little or no warning before it was exploited.
The flaw allowed a low-privileged user on a shared server to bypass expected isolation controls, including CloudLinux CageFS. It could then append data to files with root-level privileges.
In plain English, a user who should have been confined to one small hosting account found a way to reach into the wider server.
The attacker gained root-level access and deployed a webshell across hundreds of accounts on that server. A webshell is a hidden tool that gives an attacker remote control over parts of a website or server. Hostinger detected unauthorised commands on a smaller number of those accounts.
According to Hostinger’s incident report, the activity was sophisticated, near-continuous and appeared to be automated or AI-driven.
That does not mean every affected website was independently hacked. It means the shared server itself had become the problem.
A secure website is only as isolated as the infrastructure underneath it.
What does “shared hosting” really mean?
Shared hosting is often presented as a simple and affordable way to put a website online. That can be perfectly reasonable for a small brochure site, campaign page or early-stage business.
The important detail is that many separate customers use the same physical server. Their websites may have different usernames, folders and control panels, but they still depend on shared infrastructure.
The hosting provider normally uses isolation technology to keep those customers apart. CloudLinux CageFS, for example, is designed to give each account a restricted view of the server. One tenant should not be able to see another tenant’s files, processes or system settings.
Think of it like a block of flats. Each business has its own locked room, but the building, lifts, power supply and security systems are shared.
If one tenant has a problem, good building security should stop it spreading. But if a flaw lets someone bypass the locks, the problem is no longer limited to one room.
That is what made the LiteSpeed vulnerability so serious. It could defeat the boundary that shared hosting depends on.
Why customers could not simply patch this themselves
A common reaction to incidents like this is: “Why did the website owner not install the update?”
In this case, the customer generally could not.
LiteSpeed Web Server is server-level software. It is managed by the hosting provider, not by the individual business renting a shared account. A customer might be able to update WordPress, plugins or themes, but they cannot usually replace the web server software or apply a root-level security fix.
This is one of the biggest differences between owning your infrastructure and renting managed hosting.
When a zero-day affects the platform, the host has to:
- Identify which servers are exposed.
- Confirm the vulnerable software and attack path.
- Obtain or validate the vendor’s fix.
- Patch the infrastructure safely.
- Check for signs of compromise.
- Restore affected websites if necessary.
- Communicate with customers.
In this incident, Hostinger says it disabled external access to the affected server, suspended the attacker’s accounts, removed malicious scheduled tasks and preserved evidence for forensic analysis. It also disabled an internal tooling integration after observing attacker activity against it.
Hostinger worked with LiteSpeed and deployed version 6.3.7 Build 2 across its entire shared hosting fleet by 23:00 UTC on the same day.
That is a rapid response. It also demonstrates why the provider’s monitoring, skills and processes matter so much to your business.
The part that determines whether you recover
Patching stops the original route into the server. It does not automatically undo everything an attacker may have changed.
The next question is: can the affected websites be trusted?
Hostinger restored affected websites from the most recent backups taken before the attack and migrated them to a new server. That combination matters:
- Recent backups reduce the amount of lost work.
- Separate recovery copies help prevent backups being overwritten by an attacker.
- A clean replacement server provides greater confidence that the original environment is no longer carrying hidden changes.
- A tested restore process means recovery is more than a promise in a sales brochure.
For a growing business, this is where hosting becomes a business continuity issue. If your website takes bookings, generates leads, processes payments or supports your staff, a hosting incident can quickly become an operational and reputational problem.
A backup that has never been restored is only a theory.
A plain-English timeline
Here is the incident in simple terms:
- Before 16 September: A previously unknown LiteSpeed vulnerability existed in affected versions of the server software.
- 16 September, 16:08 UTC: Hostinger monitoring detected unusual activity on one shared server in Brazil.
- Within minutes: The security team investigated and identified a sophisticated attack.
- During the attack: The attacker gained root-level access and placed webshells across hundreds of hosting accounts.
- Response: Hostinger isolated the server, suspended attacker-controlled accounts, removed malicious scheduled tasks and preserved evidence.
- Same day: Hostinger worked with LiteSpeed to confirm the fix and deployed LiteSpeed 6.3.7 Build 2 across its shared hosting fleet by 23:00 UTC.
- Recovery: Affected websites were restored from pre-attack backups and moved to a new server.
The incident was reported by The Hacker News and Security Affairs, which highlighted the risk of a single low-privileged hosting account becoming a route to root access across a shared server.
Questions to ask your hosting provider this week
You do not need to become a server engineer. You do need clear answers.
Ask your provider:
- What isolation technology protects customers on the same server? Is it container-based isolation, CageFS or something comparable?
- Can you offer dedicated resources or a dedicated server if our risk or traffic increases?
- What is your emergency patching SLA for critical vulnerabilities and zero-days?
- Who monitors the infrastructure outside office hours? Is there genuine 24/7 monitoring?
- Is malware scanning included, and does it scan files as well as website activity?
- Is a web application firewall included?
- Are backups hourly, daily or something else?
- Are backups stored separately from the production server?
- How long are backups retained?
- When was the last full restore actually tested?
- How would you tell us if our account was affected by a wider server incident?
- What happens if the shared server itself needs to be replaced?
If the answers are vague, that is useful information. It may be time to review your hosting arrangements.
What growing businesses can do now
First, establish whether your website is on shared hosting and what software runs underneath it. Your web developer may not know; your hosting provider should.
Next, make sure you have ownership of your domain, website files, database and recovery copies. Do not assume that “the host has backups” means you can recover quickly, or that the backups are independent.
You should also keep your content management system, plugins, themes and administrator accounts secure. These controls would not have prevented the LiteSpeed zero-day, but they reduce the number of other routes an attacker can use.
Finally, consider whether your business has outgrown basic shared hosting. A managed hosting service with proactive monitoring, hardened infrastructure, tested backups and clear support gives you someone responsible for the platform beneath your website.
That is particularly important for firms in Cardiff, South Wales and elsewhere in the UK that rely on their website every day but do not have an in-house infrastructure team.
Picnic IT provides managed hosting services designed around monitoring, backups, security and dependable performance. We also provide managed IT services and cybersecurity for small business, so hosting, IT support for growing businesses and security planning can be considered together rather than as separate problems.
Key Insights
- A shared hosting account may sit alongside hundreds of other websites on the same server.
- Tenant isolation is a vital security boundary, but a server-level zero-day can sometimes bypass it.
- Customers usually cannot patch a vulnerability in the host’s core server software themselves.
- Fast detection and emergency patching reduce the window in which attackers can operate.
- Malware scanning, firewall protection and forensic investigation are essential after a server compromise.
- Backup quality and restore testing determine how confidently a business can recover.
- The right hosting model should change as your website becomes more important to your operations.
The real lesson: ask who is watching the server
The LiteSpeed incident was not simply a story about one hosting company or one vulnerable product. It was a reminder that your business inherits some of the risks of the infrastructure it rents.
You can do everything right at website level and still depend on someone else to monitor the server, patch the platform, detect unusual behaviour and recover cleanly when something goes wrong.
That is not a reason to panic. It is a reason to ask better questions.
If you would like to review your current hosting, backup or security arrangements, contact Picnic IT. We are happy to have a straightforward conversation about what your business needs now, and what it may need as it grows.