The most effective way to stop one hacked WordPress site from reaching the others is to give every site its own security boundary: a separate non-privileged Unix or hosting user, its own document root and PHP process boundary, a separate database and database user, unique secrets, and backups stored outside that boundary. Putting several installations under one cPanel account or one Unix user is weak containment because a webshell, stolen panel credential, or writable directory can provide a route into the neighboring sites.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Isolation reduces the blast radius; it does not make a site impossible to compromise. You still need least-privilege permissions, encrypted administration, tested off-host backups, monitoring, and a recovery procedure that assumes credentials may have been stolen.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →What “isolating WordPress sites” actually means
Isolation is not a label on a hosting plan. It is a set of technical boundaries that prevent code, credentials, processes, databases, and backups belonging to one installation from being used against another.
Filesystem boundary
Each site should have a separate document root, owned by a distinct non-privileged Unix user. The web process for Site A should not be able to list, read, or write Site B’s files. This matters because a successful plugin exploit or uploaded webshell runs with the permissions available to the compromised process. If that process can traverse sibling directories, the attacker can search for other wp-config.php files, replace plugins, add administrator accounts, or plant persistence in another installation.
Process and PHP boundary
Separate PHP workers or pools make it harder for one site to consume resources or inherit the execution context of another. A provider should be able to tell you which Unix user executes PHP for each site and whether workers are shared. A separate pool is stronger than merely placing sites in different folders.
Database boundary
Every installation should have its own database and its own database user. WordPress’ Advanced Administration Handbook recommends separate databases managed by different users when multiple blogs share a server. If Site A’s database credentials are exposed, a distinct database user prevents those credentials from directly modifying Site B’s tables.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Secrets, logs, and backup boundary
Use unique database passwords, salts, API tokens, SFTP keys, and panel credentials per site. Keep logs attributable to one installation and store backups outside the account or server that hosts the live files. A backup that an attacker can delete or rewrite is not a reliable recovery copy.
Why sites on one account can compromise one another
WordPress warns that if a website on a shared server is compromised, another website can potentially be compromised even when its own hardening is correct. The risk is highest when several sites share one hosting account or one Unix identity.
One Unix user, many document roots
Suppose three game-news sites run as the same account. A vulnerability in a plugin on one site gives an attacker the account’s file permissions. The attacker may then scan every sibling directory, edit another site’s configuration, upload a malicious plugin, or read private backups. Changing folder names or adding obscure URLs does not create an access boundary.
Shared hosting-panel credentials
A stolen cPanel, control-panel, or deployment credential can be more powerful than a WordPress administrator account. Depending on the provider, it may expose every document root, database, cron job, email setting, backup, and DNS control in the account. Separate WordPress administrator passwords do not mitigate a stolen hosting credential.
Recommended Free Tools
Database users with broad access
Reusing one MySQL user for several sites means a compromise of one wp-config.php can expose every database to that user. Even if table prefixes differ, the account may still be able to read or alter all tables. Prefixes are organization aids, not an authorization boundary.
Shared writable locations and backups
Shared upload directories, temporary folders, deployment shares, or backup archives can become cross-site infection points. An attacker who can write a PHP file into a location executed by another site can bypass otherwise careful WordPress settings.
Choose an architecture with a clear blast radius
The following comparison describes typical boundaries. Actual implementation varies, so ask the provider to document the Unix user, process, filesystem, database, and backup separation rather than relying on a marketing tier name.
| Architecture | Filesystem and process isolation | Database and secrets | Stolen hosting credential | Backup boundary | Cost and operations | Centralized deployment |
|---|---|---|---|---|---|---|
| Several sites under one hosting account or Unix user | Weak; sibling files are often reachable and processes may share an identity. | Frequently reused unless you build separation yourself. | Can expose every site in the account. | Usually one shared backup set and recovery boundary. | Lowest overhead, but the largest blast radius. | Easy because everything is in one account. |
| Separate hosting accounts on one provider | Good when each account has a distinct non-privileged user, document root, and PHP boundary. | Use a database and database user per site; keep secrets separate. | Normally limited to the compromised account, but verify panel privileges and provider-level access. | Each account can have its own retention and restore process; keep an off-host copy. | Moderate recurring cost and administration. | Possible through a central deployment system, provided it does not use one all-powerful credential. |
| Isolated containers or virtual machines | Strong process and filesystem boundary when configured correctly; the host remains a higher-level trust boundary. | Run separate databases or database users and separate secret stores per site. | A site credential normally stays inside its container or VM; a host or orchestration compromise can affect all tenants. | Back up each workload independently and protect the backup system from the host. | Higher operational skill and monitoring requirements. | Strong automation options, with careful separation of deployment credentials. |
| Separate physical or fully independent servers | Strongest practical separation between sites. | Independent databases, secrets, logs, and administration. | A stolen credential is generally confined to one server unless it is reused elsewhere. | Independent backup and restoration boundaries. | Highest cost and maintenance overhead. | Centralized deployment requires more tooling and coordination. |
Separate accounts are a practical baseline for most collections of WordPress sites. Containers or independent servers make sense when a compromise would have unusually high consequences, when regulatory separation is required, or when you already operate the necessary infrastructure.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Build the minimum safe baseline
1. Inventory every access path
Create a per-site record before moving files. Include the domain, document root, Unix user, PHP pool, cron jobs, database name, database user, SFTP or SSH keys, hosting-panel users, API tokens, deployment integrations, DNS access, and backup destinations. Include staging sites and abandoned installations; an unmaintained subdomain can be the entry point that defeats an otherwise strong design.
2. Put each site in its own user boundary
Move each installation into a separate hosting account or isolated user where feasible. Ask the provider these specific questions:
- Which Unix user executes PHP for this site?
- Can that user traverse or write another customer’s document root?
- Are PHP workers, temporary directories, cron jobs, and environment variables shared?
- Can a control-panel user for one site view another site’s files, databases, backups, or logs?
- Does a provider-level administrator or support workflow bypass these boundaries, and how is that access audited?
A “managed WordPress” label does not answer these questions. Obtain the actual boundary description in writing.
3. Give every installation a database and database user
Create one database and one database user for each site. Store only that site’s credentials in its own wp-config.php; never reuse a database password across installations. Do not treat table prefixes as isolation.
Free tools Windows power users keep installed
One-click scans. No signup required.
WordPress identifies SELECT, INSERT, UPDATE, and DELETE as the normal operational privileges. Schema-changing work, such as an upgrade that creates or alters tables, may require temporary elevation. If you restrict privileges, test the full update, plugin-installation, migration, and recovery workflow first, and have a verified backup before granting anything broader.
4. Restrict filesystem writes
Keep WordPress core, administration code, themes, and plugins controlled by the site owner or deployment process. Permit web-server writes only where the application genuinely needs them, normally the uploads area and other explicitly required runtime directories. Avoid broad world-writable permissions and do not make the entire document root writable just to simplify plugin installation.
Where possible, deploy code through SFTP, SSH, or a controlled pipeline rather than allowing the web process to rewrite its own executable files. If automatic updates require temporary write access, schedule the change, perform the update, and restore the narrower permission model afterward.
5. Disable unnecessary remote access
Turn off remote database access unless a documented application needs it. If it is required, restrict it to known source addresses and encrypted connections. Use encrypted SFTP or SSH instead of plaintext FTP, and remove old keys when a contractor, employee, or deployment system no longer needs access.
6. Separate scheduled jobs and integrations
Review cron jobs, server-side scripts, webhooks, analytics tokens, payment integrations, and content-import tools. A single automation credential that can publish or write to every site undermines filesystem separation. Create per-site tokens with the smallest scope available and record who owns each one.
7. Keep backups outside the live boundary
Store backups in a different account or service, protect them from deletion by the live-site credential, and retain an immutable or otherwise protected copy. Back up the database, uploads, themes, plugins, configuration, and any deployment metadata needed to rebuild the site. Test restoration before an incident: a backup that cannot be restored within your required time is only an assumption.
Verify that isolation is real
Do not accept “the sites are isolated” without a testable explanation. Perform these checks with your provider or administrator:
- Log in as Site A’s Unix or SFTP user and confirm that Site B’s directory cannot be listed, read, or modified.
- Inspect the PHP execution user and pool for every site; confirm that they are not all the same identity when your design promises separation.
- Attempt a database connection using Site A’s credentials and verify that Site B’s database is not visible or writable.
- Check temporary directories, shared sockets, cache paths, and upload locations for cross-site write access.
- Review panel roles and API tokens to ensure a credential issued for one site cannot administer all sites.
- Restore a single site into a clean test location and confirm that the procedure does not require exposing the others.
Run these checks after provider migrations, account consolidations, PHP changes, or control-panel redesigns. Isolation can silently disappear when infrastructure is changed.
Use layered controls around the boundary
WordPress-level hardening
Keep core, themes, and plugins maintained; remove software that is no longer needed; use strong, unique administrator credentials; and limit administrator accounts. These controls reduce the chance of initial compromise but cannot compensate for a shared Unix identity.
Web-server and PHP controls
Prevent execution of PHP in upload directories unless a specific application component requires it. Disable unused PHP features and administrative endpoints according to your hosting environment, and limit outbound network access for workloads that do not need it. Apply these settings per site where possible, rather than globally in a way that breaks another installation.
Monitoring and file integrity
Record authentication, panel, SFTP, database, and WordPress administrator events. Alert on new administrator accounts, unexpected PHP files, changes to core or plugin code, database users, cron jobs, and outbound connections. Keep logs outside the site’s writable directories so an attacker cannot erase evidence by editing the web root.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to do when one site is hacked
Isolation is a containment measure, not an incident-response plan. Treat a compromise as a potential exposure of every credential and integration that the affected site could reach.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute- Contain without destroying evidence. Take the affected site out of service or place it behind a maintenance response. Preserve a copy of files, logs, the database, and relevant timestamps before cleaning, if your response process permits.
- Check the neighboring boundaries. Look for modified files, new users, suspicious cron jobs, database changes, and unusual logins on every site that shared a server, panel, deployment key, or database host.
- Review every access plane. Examine SFTP or FTP, SSH, the hosting panel, WordPress administrator accounts, database accounts, API tokens, webhooks, and DNS or CDN controls.
- Rotate credentials. Replace hosting, panel, SFTP or SSH, database, WordPress, API, and deployment credentials. Revoke old keys and tokens rather than merely changing one password.
- Rebuild or restore from known-good material. A clean rebuild from verified core files and reviewed content is preferable to trying to delete an attacker’s files one by one. Restore the database and uploads only after checking them, and patch the original entry point before reconnecting the site.
- Close the route and document decisions. Remove the vulnerable plugin or integration, tighten the boundary that failed, preserve the timeline, and record which sites and credentials were examined.
Do not restore a compromised backup blindly. A backup made after the attacker gained access may contain the same webshell or altered administrator account.
Common designs that look isolated but are not
Separate folders under one account
Folders organize files; they do not change Unix permissions. If one PHP process can read the parent directory, the sites are not isolated.
Different domains with one database user
Separate domains and table prefixes do not stop a database user with broad rights from reading or altering every table it can access.
One “master” deployment key
A central key that can write to every site makes deployment convenient but turns a single stolen key into a collection-wide compromise. Use per-site keys or a brokered system that grants only the required target access.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallBackups stored in the same panel account
An attacker with panel access can often delete both live files and backups. Keep at least one protected copy outside that credential boundary.
Assuming a premium hosting tier guarantees separation
Price and branding do not prove filesystem or process isolation. Ask for the execution user, PHP pool model, database ownership, panel permissions, and backup design.
How to choose the right level of separation
Use one separate non-privileged user, document root, database, and database user per site as the minimum for a small portfolio. Choose separate hosting accounts when you want a manageable operational boundary and can accept moderate additional administration. Choose containers or virtual machines when you need stronger process isolation and have the skills to patch and monitor the host. Choose independent servers when the sites must remain separate even if one machine or hosting account is fully compromised.
Balance isolation against deployment and recovery complexity. Centralized automation is useful, but its credentials must be more carefully protected than any individual site key. The right architecture is the one whose boundaries you can explain, test, monitor, and restore—not the one with the most impressive plan name.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
