Three Days Unnoticed: The First Link in the Chain Is the One You Control

Nov 11, 2026 · @Thomas J. Raef

One site, three days, 400 accounts

On November 5, an attacker broke into a single website on a Hostinger shared server in Phoenix. The way in was a vulnerable content management system (CMS) on one customer’s site. Nothing unusual so far. Sites get compromised this way every day.

What happened next is the part worth studying. Over the following three days, the attacker found and exploited a previously unknown flaw in LiteSpeed Web Server. That flaw let code from one website get past CloudLinux CageFS, the layer that keeps hosting accounts separate. From there the attacker reached root-level access on the server.

By the time it was contained, the attacker had run code or read credentials on about 400 accounts. That included database credentials and access tokens. All of it started from one site that belonged to somebody else.

Hostinger handled this well

This is not a story about a careless host. A zero-day is, by definition, a flaw nobody knew to patch. What a host can control is how fast it detects, contains and discloses. On those counts, Hostinger’s own report reads well:

• Its security monitoring flagged suspicious activity on November 8.
• It declared an incident at 12:26 UTC on November 9, removed the attacker’s access and rotated internal credentials.
• From 13:30 UTC it moved every account to other servers and restored affected sites from backups taken before the attack.
• It found no evidence that its internal management systems, backup system or account login systems were compromised.
• LiteSpeed released a fix on November 10, and Hostinger had it on all shared hosting servers by 16:03 UTC that day.
• It emailed affected customers individually and published a plain-language account of what happened.

The damage was limited to one server out of more than 5,000. That is a fast, transparent response, and other hosts should take notes.

The three days nobody was watching the site

The detail that matters most is the gap between November 5 and November 8. For three days, a compromised website sat on that server and nobody knew.

Hostinger explains why. The attacker’s code ran as the shared web server user, so its activity blended in with normal server traffic. From the server’s point of view, a hacked site running code looks a lot like a healthy site running code.

From inside the site, the picture is usually different. Hostinger has not said what the attacker placed on the customer’s site, and we won’t guess. But we have been cleaning up hacked websites since 2007, and a foothold almost always leaves marks: a new file, a modified file, a user account that wasn’t there yesterday. Those are exactly the changes that site-level monitoring exists to catch.

We can’t say for certain how this one would have played out. What we can say is that a site owner watching their own files would very likely have known something was wrong well before day three.

That matters because of what the attacker was doing with the time. According to Hostinger, it took those three days to find and exploit the LiteSpeed flaw. Every day the foothold survived was another day of work on the next step. Remove the foothold early and the chain may well have ended at the first link.

This time it was LiteSpeed

It would be easy to read this as a LiteSpeed problem. It isn’t. LiteSpeed’s changelog describes the fix as a change to Apache configuration handling that had allowed access to files outside the document root and script execution without suEXEC. It shipped within a day of Hostinger’s report.

Every layer underneath a website has had its turn:

• Apache, 2019. CVE-2019-0211 let anyone who could run a script on a shared server gain root.
• The Linux kernel, April 2026. Copy Fail (CVE-2026-31431) allowed privilege escalation on Linux systems.
• PHP, October 2026. The php2shell vulnerabilities could, in the worst case, let an attacker run their own code on a server.
• LiteSpeed, September 2026. An earlier zero-day gave an attacker root on a Hostinger server in Brazil.

The layer changes. The first step never does. In shared hosting, an escape like this needs somewhere to start, and that somewhere is a website that got compromised and stayed compromised.

The window to notice is shrinking

Nothing in Hostinger’s report says AI was used in this attack, and we are not claiming it was. But three days from a single-site foothold to a brand new server escape fits a pattern the whole industry is watching.

• Cogent Research analyzed 69,159 CVEs and found the time to develop an exploit for a known vulnerability fell from 125.3 days in January 2025 to 0.5 days by April 2026, as reported by Dark Reading.
• Mandiant’s M-Trends 2026 report found 28.3% of CVEs exploited within 24 hours of disclosure, as cited by Chainguard.
• XBOW’s researchers directed AI agents to build a working three-stage Chrome exploit chain in six days, according to a Cloud Security Alliance research note. That was an experienced team, not a beginner.

Chaining one weakness into the next used to take rare skill and a lot of patience. AI tools are making that work faster and cheaper. For a site owner, the practical meaning is simple: the time between “my site was compromised” and “it became something much worse” is getting shorter.

The link you control

You can’t patch a zero-day in your host’s web server. You can make sure your site is not the place an attack like this begins.

1. Keep your CMS and its extensions updated. Remove the ones you no longer use. The entry point here was a vulnerable CMS, not the zero-day.
2. Monitor your own files. Your host watches the server. Watching your site for new and changed files is a different job, and it is yours.
3. Act on alerts quickly. A foothold found on day one is a cleanup. A foothold found on day three can be a server-wide incident.
4. Rotate credentials after any incident on your server. If your host reports a breach, change database passwords and access tokens even if your site looks fine. About 400 accounts in Phoenix had theirs exposed.
5. Keep backups you control. Hostinger’s pre-attack backups made a same-day recovery possible. Have your own copy as well.

Hostinger did its part and did it quickly. The lesson for the rest of us is about the three days before anyone noticed. The first link in the chain is the one you control. Watch it.

Watching that first link is what we do at We Watch Your Website. We monitor your site’s files for new and changed code and alert you when something appears that shouldn’t be there, so a foothold gets found and removed before it becomes something bigger.

Sources

• Hostinger: Unauthorized access to our Phoenix server, November 2026 incident report
• LiteSpeed Web Server changelog, 6.3.7 Build 9
• webhosting.today: Hostinger traces a Phoenix server attack to a LiteSpeed zero-day
• Hostinger: How we responded to a LiteSpeed zero-day attack (September 2026)
• Hostinger: protections against php2shell PHP vulnerabilities
• BleepingComputer: Apache bug lets normal users gain root access via scripts
• Wikipedia: Copy Fail (CVE-2026-31431)
• Dark Reading: AI-assisted exploit development outpaces scanner detection
• Chainguard: 2026, the year of AI-assisted attacks
• Cloud Security Alliance: Six Days, $40,000: AI-Assisted Chrome Full-Chain Exploit