When multiple WordPress sites share the same PHP user, if one site is compromised, attackers may leverage the same runtime identity and file permissions to read from or write to other sites. This article uses a real case to explain the causes of cross-site infection and how WP Panel reduces risk through independent system users, independent PHP-FPM pools, file permissions, database isolation, file locks, and change monitoring.
Case Overview
This article shares our experience from a real case where sites on the same server were cross-infected. The basic situation of this case is as follows:
- On the same server, two websites have different domains, databases, and WordPress backends;
- However, PHP runs as the
wwwuser; - After controlling one site, the attacker gains the ability to write files on the server;
- The other site allows
wwwwrites, and a backdoor was laterally implanted.
Root Cause of Infection
The root cause of this problem is not that the two websites use different domains, databases, or WordPress backends, but that their PHP processes run as the samewwwuser, and this user has write permissions to multiple website directories. This is exactly the difference between WP Panel and some shared PHP user solutions in terms of runtime identity model.
Traditional shared identity: all websites share the www user.
site-a ─┐
site-b ─┼─→ PHP-FPM: www → all website directories
site-c ─┘
WP Panel: each website has its own independent user.
site-a → PHP-FPM pool A → user wp_site_a
site-b → PHP-FPM pool B → user wp_site_b
site-c → PHP-FPM pool C → user wp_site_c
Under WP Panel's default model, even if an attacker compromises site A, site A's PHP process still runs as its own system user; without further bypassing PHP restrictions or obtaining higher system privileges, it typically cannot write to site B, nor can it read site B'swp-config.phpwith permissions 0600. This cuts off the most direct lateral implantation path in this case (but it should not be understood as absolute isolation at the container or virtual machine level).
How WP Panel Reduces Cross-Site Infection Risk
In addition to separate Linux system users and user groups, WP Panel also does the following to reduce the risk of cross-site infection:
- Independent PHP-FPM pool and socket per site;
- PHP processes run as the site's user;
- Set per site
open_basedir； - Disable
exec、shell_exec、system、passthru、proc_open、popen； wp-config.phpUse 0600;- Independent database and database user per site;
- Database users can only access their own site's database;
- Each PHP-FPM pool has an independent process limit, so it will not directly consume other sites' process quotas;
- File lock can make the code directory read-only: standard mode keeps upload and cache directories writable, strict mode keeps only the upload directory writable;
- Sites with file lock enabled can establish an off-site SHA-256 code baseline and check for changes hourly;
- After enabling anomaly monitoring, check hourly for changes to administrators, content, application passwords, critical settings, and database persistent objects;
- Nginx, Fail2ban, and nftables provide blocking or automatic banning for high-frequency requests, login brute force, sensitive file scanning, massive 404 probing, and high-confidence SQL injection URLs.
For example, if your server's WordPress login page is under continuous brute force attacks, once the relevant requests reach the rule threshold, Fail2ban will automatically ban the source IP; repeated attacks will result in progressively longer ban times. It can greatly reduce the risk of mass brute force attacks.
For example, if a website has been compromised, administrator profiles modified, administrator accounts added or deleted, or privileges escalated, enabling anomaly monitoring can detect changes at hourly sampling and notify you through the email or Webhook alert channels you enabled in the panel. Its purpose is to alert you early for manual investigation; it does not automatically determine or remove malicious code.
For example, if you do not need to frequently install or modify plugins and themes, you can enable file lock to shorten the time the code directory is writable; when maintenance is needed, operate through the panel's temporary maintenance window or controlled update process. File lock does not mean the entire site is completely unwritable; the upload directory will still retain write permissions, and you should confirm that the existing code is clean before enabling it.
What Would Happen If the Sites in This Case Used WP Panel?
| Attack steps in this scenario | WP Panel corresponding defense |
|---|---|
| Website A's admin panel compromised | When login brute force reaches the threshold, the source IP can be automatically banned; anomaly monitoring can detect some account changes, but cannot guarantee passwords will never be leaked |
| Upload malicious plugin | When file lock is in locked state, it can prevent writing to the code directory; legitimate maintenance requires using the temporary maintenance window or panel-controlled updates |
| PHP file manager accesses server directories | Independent users,open_basedirand disabled command functions together limit capabilities, but this is not a kernel-level sandbox |
| Write to Website B | Website A's PHP user does not have write permission to Website B; if an attacker further gains higher system privileges, that is outside the scope of this isolation layer's promise |
| Read Website B's database password | wp-config.php0600, readable only by Website B's user |
| Modify Website B's database | Website A's database user does not have permissions for Website B's database |
| Inject new administrator/application password | Once anomaly monitoring is enabled, relevant changes can be detected through hourly sampling, but it is not real-time auditing |
| Long-term persistence after code modification | The SHA-256 baseline established after enabling file locking can generate change alerts; the initial baseline itself cannot prove the code is clean |
Is WP Panel Absolutely Secure?
No, WP Panel only provides security protection for your website within its capabilities, but:
- WP Panel is not container or virtual machine isolation;
- WP Panel is not a complete WAF;
- WP Panel is not a malicious code scanner;
- WP Panel does not automatically detect and remove viruses;
- CPU, memory, disk I/O, network, and whole-machine services such as Nginx, PHP-FPM, MariaDB, and Redis are still shared; the panel does not have per-site cgroup resource quotas;
open_basedirand disabling PHP functions are not kernel sandboxes; regular code files use standard permissions, and if an attacker bypasses PHP restrictions and gains system-level execution capability, they may still be able to read regular code files of other sites;- Backdoors that already existed before file locking was enabled may enter the initial baseline;
- Anomaly monitoring is disabled by default, and hourly sampling is not real-time auditing;
- root privileges or kernel-level vulnerabilities are not within the scope of the standard site isolation commitment.
The WP Panel cannot replace proper security habits
- WordPress administrators should use independent strong passwords;
- Regularly update core, themes, and plugins;
- Do not install file managers from unknown sources;
- Regularly check application passwords;
- Enable file locking and anomaly monitoring;
- Regularly create backups of databases and website files, and sync important backups off-site;
- Before launching a new site or enabling file locking, first confirm that the current code is clean, then establish the initial baseline.
If you run multiple WordPress websites on a Debian 13 VPS, the focus of WP Panel is not to promise „absolutely no mutual impact,“ but to establish clear system user, PHP-FPM, file, and database boundaries for each website, so as to limit a single-site intrusion to that site as much as possible. When an intrusion actually occurs, you must still immediately isolate the affected site, check alerts and logs, and handle it using a clean backup that is confirmed to be recoverable.
