What happens when one site gets hacked on shared hosting?

Managing client sites at scale requires thinking about infrastructure security in ways beyond simply installing security plugins or enforcing strong passwords.

When you host dozens or hundreds of WordPress sites, the hosting architecture becomes a security consideration that can either protect your entire portfolio or put it at risk.

Traditional shared hosting keeps costs down, but it also means that sites share the same file system, process space, and network stack. As such, when one site on a shared server is compromised, the malware can spread to other sites.

The hidden security risks of shared hosting environments

Each site on a shared hosting server uses a portion of the server’s CPU, RAM, and storage. This makes sense for hosting providers from a cost perspective and keeps customer prices accessible.

However, from a security perspective, there are vulnerabilities that scale with the number of sites you manage. The core issue centers on resource sharing. File permissions and user isolation can provide some protection, but these are software-level controls that can be exploited. After all, phishing attacks, malware, and ransomware remain the leading threats to any site.

Understanding ‘lateral spread’ and ‘cross-contamination’ can help clarify the risks:

• Lateral spread refers to malware moving from one compromised system to other systems within the same network or environment.
• Cross-contamination happens when a security issue affecting one site spreads to other sites sharing the same infrastructure.

If you manage client portfolios, saving money using shared hosting can be attractive. However, a single client’s outdated plugin or weak password can pose a threat to your entire hosting setup.

When you factor in the time spent monitoring for threats and recovering from security incidents across multiple sites, the value drops.

How malware spreads between sites on shared servers

The exact nature of any cross-site contamination depends on how the hosting provider implements user separation and file permissions. Even so, the fundamental problem remains consistent across most shared hosting setups: these environments create attack surfaces where compromised accounts can access other users’ files through misconfigured permissions or vulnerable scripts.

The pathways for cross-site infection include:

• PHP scripts read files from other user directories when permissions are configured incorrectly.
• Shared temporary directories allow malware to spread between sites.
• Server-level vulnerabilities enable processes from one site to affect others.
• Compromised user accounts gain access to neighboring directories through shared resource pools.

Kinsta customer Bookswarm discovered this issue while managing hundreds of client sites on a shared hosting platform. They found that the mixed server setup created security headaches alongside any individual site compromises. The architecture meant that “an attack on one was an attack on others.”

This also creates an operational burden as you need constant monitoring to catch compromises before they spread. If one site shows signs of infection, you have to check every other site on the same server. Incident response becomes a portfolio-wide exercise rather than an isolated fix.

The blacklist contamination problem

Shared IP addresses create another layer of risk in traditional shared hosting. When multiple sites share the same IP, they also share the same reputation in the eyes of email providers, search engines, and security services.

Because a single compromise can lead to the entire IP address being blacklisted, every site on that IP suffers from several cascading problems:

• Email deliverability drops across your entire portfolio when one compromised site triggers spam filters such as Spamhaus.
• Search engines flag the shared IP as suspicious, negatively affecting rankings for all associated sites.
• Security services and firewalls block requests from the IP, breaking functionality for sites unrelated to the original compromise.
• Client sites lose trust indicators when security tools associate the shared IP with malicious activity.

The recovery process from IP blacklisting requires a coordinated effort with your hosting provider. You need to identify which site caused the problem, clean it up, and then request removal from various blacklists. During this process, all sites on the shared IP continue to experience the consequences.

In the meantime, you have to explain to your clients why their email stopped working or why their site got flagged, even though they followed optimal WordPress security practices. The root cause traces back to infrastructure decisions that individual site owners have no control over. All of this ongoing maintenance takes time away from client work and development projects.

Container-level isolation for WordPress hosting

Site isolation addresses many of the fundamental problems of shared hosting. For example, Kinsta runs each site in its own isolated container with dedicated resources. This means each WordPress site gets its own container that includes everything needed to run: Linux, NGINX, PHP, and MySQL.

The isolation happens at the operating system level through two core mechanisms:

• Namespaces provide each container with its own view of system resources. A process running in one container cannot see or interact with processes in another container.
• Control groups (‘cgroups’) enforce resource limits and ensure each container has access to its dedicated allocation of CPU and RAM.

What’s more, PHP threads for your WordPress site cannot see or interact with processes from other sites. This kernel-level separation prevents scenarios where one site’s compromised process attempts to access resources belonging to other sites.

Network stacks operate independently within each container, too. Each site has its own network interface and IP handling. This isolation extends through the entire stack and eliminates the noisy neighbor problem that plagues shared hosting.

When one site experiences a traffic spike or runs resource-intensive operations, it only affects that site’s container. The dedicated resource allocation means other sites continue operating with their full allocation regardless of what happens elsewhere on the infrastructure.