Shared hosting is built on a promise of separation: one customer’s vulnerable website should not become every other customer’s incident.
A newly disclosed Hostinger incident illustrates why that promise must be supported by multiple, independently effective controls. The hosting provider reported unauthorised access to one shared server in Phoenix, Arizona, after an attacker first compromised a customer website and then used a previously unknown vendor vulnerability to escape the expected account-isolation boundary. Hostinger says the attacker ultimately achieved root-level access and was able to execute code or read credentials across roughly 400 customer accounts.
The company’s public account is unusually useful because it exposes a common attack progression: application compromise, tenant escape, privilege escalation, credential exposure, and a high-tempo containment operation.
For organisations operating multi-tenant environments—and for customers of hosting providers—the lesson is clear: isolation is essential defence in depth, but it cannot be the only line of defence.
What Hostinger has confirmed
According to Hostinger’s incident report, suspicious activity was detected on November 8, 2026. Its investigation determined that the initial access occurred on November 5 through a vulnerable content-management system on one customer website.
Over the following days, the attacker identified and exploited a previously unknown vulnerability in software used to serve websites. That flaw enabled code running from one website to bypass the isolation provided between accounts by CloudLinux CageFS, eventually reaching root-level access on the affected server.
Hostinger says that approximately 400 accounts may have had code executed or credentials read, including database credentials and access tokens. It says it found no evidence that its internal management systems, customer-login systems, backups, or backup-encryption keys were compromised.
These are the confirmed facts. The provider has not publicly named the attacker, published a CVE identifier for the escape vulnerability, or provided evidence that the exposed credentials were subsequently used. It is important not to turn an incident report into broader claims that the available evidence does not support.
Why one vulnerable website became a server-level problem
Shared hosting has a difficult security model. It needs to let many unrelated customers run code on the same server while preventing one account from reading another account’s files, credentials, processes, or configuration.
Controls such as per-user permissions, containers, jailed filesystems, web-server separation, and resource limits reduce the likelihood that a compromised customer site can affect its neighbours. They do not remove that possibility entirely.
In this case, the initial vulnerable CMS was not the full incident. It was the entry point. The more consequential failure was the ability to cross a tenant boundary and obtain a higher privilege level.
This is a useful distinction for security teams. Vulnerability management often focuses on internet-facing applications: patch the CMS, remove the vulnerable plugin, harden the admin panel. That work remains essential. But a layered design must assume one customer application will eventually be compromised and ask what prevents the compromise from spreading.
The answer should not be a single component, product, or configuration claim.
The response: contain first, preserve options
Hostinger declared an incident on November 9, removed the attacker’s access, rotated internal credentials, and preserved evidence for forensic work. Beginning at 13:30 UTC, it moved accounts and websites away from the affected server and restored affected sites from backups created before the compromise. The original server was taken offline for investigation.
That response pattern is worth examining.
Moving customers to clean infrastructure may be disruptive, but it creates a clearer trust boundary than attempting to clean and continue running a server where root-level access may have occurred. Restoring from pre-compromise backups can also reduce persistence risk—provided those backups are themselves protected, tested, and outside the attacker’s reach.
Hostinger’s report notes that the attacker’s activity initially blended with normal web-server activity because the code ran as the shared web-server user. This reinforces the value of behavioural detection: unusual processes, outbound connections, credential-file access, abnormal database activity, cross-account access attempts, and privileged command execution may be more meaningful than a generic “malware detected” alert.
What hosting providers should review
Treat application compromise as expected
A provider cannot assume every customer site is patched, securely configured, or free from vulnerable plugins. Strong tenant isolation must be designed around the likelihood that one account will be compromised.
Review how application processes are separated; what file, socket, process, and credential access is possible across accounts; and what happens when a web-server process is exploited.
Test the escape path, not only the perimeter
Red-team exercises and security reviews should include a realistic question: “If an attacker achieves code execution in one tenant, can they reach another tenant or gain host-level privileges?”
This should cover web-server workers, PHP or application runtimes, temporary directories, shared caches, local sockets, control panels, scheduled jobs, secret stores, and backup agents.
Protect and rotate secrets systematically
Database credentials and access tokens are particularly dangerous in a hosting incident because they can outlive the affected server. Providers should know which secrets each customer account can access and have a tested way to rotate, revoke, or invalidate them at scale.
Customers should similarly avoid storing long-lived, high-privilege credentials in web roots, deployment directories, or environment files readable by application processes.
Preserve forensic evidence without delaying recovery
A compromised server should not be casually rebooted or rebuilt before relevant evidence is preserved. At the same time, an investigation cannot become an excuse for keeping potentially compromised infrastructure online.
A good incident plan separates those objectives: isolate the server, preserve an immutable snapshot and logs, move workloads to known-clean infrastructure, and retain a defensible timeline.
What customers of shared hosting should do
Customers should not interpret provider-managed isolation as a substitute for application security. Patch CMS platforms, themes, plugins, and dependencies promptly. Remove inactive components. Use unique credentials per site and minimise what is stored in the hosting account.
Where feasible, use separate database users, scoped API tokens, external secret management, multi-factor authentication for hosting-control panels, and backups that can be restored independently of the provider environment.
After a provider reports possible credential exposure, rotate database passwords, API tokens, SSH keys, deployment credentials, and integration secrets in a prioritised order. Start with credentials that could enable access to customer data, cloud environments, source repositories, payment systems, or other production services.
The takeaway
The Hostinger incident is not evidence that tenant isolation is ineffective. On the contrary, isolation remains a critical control. The lesson is that it must be paired with rapid patching, least privilege, monitoring, credential hygiene, backup resilience, and a rehearsed recovery process.
In multi-tenant environments, the security question is not whether one website can be compromised. It is whether that compromise remains one website’s problem.