Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →The most effective way to stop one hacked WordPress site from reaching your other sites is to give every installation its own security boundary: a separate non-privileged Unix or hosting user, document root, PHP worker or pool, database, database user, secrets, logs and backup set. Separate hosting accounts or isolated containers provide the strongest version of that design. If several sites must share a server, they should still run as different users that cannot read or write one another’s files, with separate databases and database users.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
A shared cPanel login, one Unix account, or one database user for every site is weak containment. A webshell, stolen SFTP credential or compromised hosting account can turn one site’s breach into access to its siblings. Isolation reduces that blast radius; it does not remove the need for patching, monitoring, protected backups and a practiced recovery process.
As an Amazon Associate I earn from qualifying purchases.
Why WordPress sites on the same account can compromise one another
WordPress code runs with the permissions of the operating-system user assigned to the web process. When several installations run as the same user, a malicious PHP file in Site A can often read, alter or add files in Site B’s document root. The same problem appears when a hosting panel, SFTP account or deployment key has access to every site: stealing one credential exposes the whole collection.
WordPress’s Hosting Handbook advises that separate websites should, where possible, run as separate users so they are isolated from one another. Its Advanced Administration Handbook also warns that if another website on a shared server is compromised, your site can potentially be compromised even when you followed the normal hardening guidance. That is a qualitative warning, not a published percentage: there is no authoritative figure establishing how often infections spread between WordPress installations.
Database permissions create a second path. If every site uses the same MySQL user, code that obtains that password can connect to every database covered by the account. A separate database user for each installation makes cross-site changes harder and gives you a clear place to revoke access.
Isolation is therefore a set of boundaries, not a product label. “Managed WordPress,” “shared hosting” and similar marketing terms do not prove that processes, files, databases or credentials are technically separated. Ask the provider how those boundaries are implemented.
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 minuteChoose an isolation level
Separate hosting accounts or isolated containers: strongest practical containment
Put each site in its own hosting account or in a container or virtual machine with its own non-privileged Unix user. Give it a separate document root, PHP worker or pool, database, database user, secrets, logs and backup set. A compromise then has fewer routes to neighboring sites, and a stolen hosting-panel credential is limited to one account if the provider’s control plane enforces that boundary.
This design costs more and requires more administration. You will manage more accounts, updates, monitoring policies and restore jobs, and a centralized deployment system needs deliberately scoped credentials. The additional work buys a substantially smaller blast radius and clearer forensic evidence.
Separate users on one server: acceptable when the boundaries are real
Several sites can share a server when each PHP process runs as a different non-privileged user and the filesystem prevents directory traversal and writes across users. Databases and database users must also be separate. Confirm that scheduled jobs, temporary directories, log files and backup destinations do not quietly reintroduce a shared path.
This arrangement is only as strong as the host’s configuration. Ask which Unix user executes PHP for each domain, whether one user can list or traverse another site’s directory, and whether a compromised process can inspect shared environment variables or process memory.
One account or one Unix user for many sites: weak containment
Multiple document roots under one account are convenient for billing and administration, but they are not a meaningful security boundary. A webshell can often move sideways, and a stolen SFTP or panel credential can edit every installation. Treat this layout as one security zone: one breach can expose all sites, databases and backups reachable through the account.
Architecture comparison
| Arrangement | Filesystem and process isolation | Database and secret separation | Effect of a stolen hosting credential | Backup and restore boundary | Cost and operations | Centralized deployment |
|---|---|---|---|---|---|---|
| Several sites in one hosting account or Unix user | Minimal; sibling files are commonly reachable | Often shared unless configured manually | Usually exposes every site in the account | One compromised boundary can reach the whole set | Lowest cost and simplest administration | Easiest, but credentials are broadly privileged |
| One non-privileged user per site on a shared server | Good only if traversal, reads and writes are blocked between users | Separate databases and users required | Limited to the account or user that the credential controls | Can be separated by site if backups are stored outside web roots | Moderate cost and operational effort | Works with per-site deployment keys and scopes |
| Separate hosting accounts | Provider-enforced account and process boundaries | Separate databases, users and secrets by account | Normally limited to the compromised account; verify panel privileges | Separate schedules and retention policies are practical | Higher recurring cost and account overhead | Requires orchestration across accounts |
| Isolated containers or virtual machines | Dedicated process, filesystem and network boundaries when correctly configured | Can be fully independent per workload | Usually confined to one instance, subject to host and orchestration controls | Independent images, volumes and off-host backups | Highest administration skill requirement short of separate hardware | Automatable, but deployment credentials must be narrowly scoped |
| Separate physical or virtual servers | Strongest separation between workloads | Independent databases, secrets and operating systems | Compromise normally stops at one server unless credentials are reused | Completely independent recovery domains | Most expensive and operationally demanding | Central deployment needs a carefully secured management plane |
Step-by-step: build isolated WordPress installations
- Inventory every access path. Record each domain, document root, PHP version and pool, cron job, database and database user, SFTP or SSH key, hosting-panel user, API token, backup destination and deployment credential. Include staging copies and abandoned domains; an overlooked installation can become the bridge into the rest.
- Pick the boundary for each site. Move high-value or unrelated sites into separate hosting accounts, containers or virtual machines where feasible. For sites that remain on one server, require a distinct non-privileged Unix user for each installation. Ask the provider, in writing, which user executes PHP and whether that user can traverse, read or write another site’s directories. Do not accept a plan name as proof of separation.
- Give every site a separate document root. Keep each installation outside the others’ directories and ensure parent directories do not grant unnecessary execute or read access. Verify that web-server aliases, symbolic links, shared temporary folders and deployment mounts cannot point one site into another site’s tree.
- Create one database and one database user per installation. Store unique credentials in that site’s
wp-config.php; never reuse a database user across sites. WordPress’s administration guidance recommends separate databases managed by different users when multiple blogs share a server. Use a distinct database name, username and password even when the database server itself is shared. - Apply least-privilege database access. Normal WordPress operation generally needs
SELECT,INSERT,UPDATEandDELETE. Schema-changing work, such as installing or updating a plugin that alters tables, may require temporary elevation. Take and verify a backup before granting broader privileges, perform the change, then return the account to the normal operational set. If your host cannot separate database users or grants, treat that as a containment limitation. - Restrict filesystem writes. Keep WordPress core, administration and plugin files controlled by the site owner or deployment process. Give the web server write access only to directories that genuinely need it, such as media uploads, and avoid broad recursive write permissions. A writable plugin or theme directory lets an attacker turn a limited file-write bug into persistent code execution.
- Separate PHP workers, scheduled jobs and secrets. Use a distinct PHP-FPM pool or equivalent worker identity for each site when the platform supports it. Run cron jobs as that site’s user, and keep API keys, salts and environment variables out of shared files and process environments. A shared worker, cron account or secret store can undo an otherwise good filesystem boundary.
- Remove unnecessary remote access. Disable remote database connections unless an application requires them, and restrict allowed source addresses when they are necessary. Prefer encrypted SFTP or SSH-based transfer to plaintext FTP. Review old keys and panel sub-users, remove those no longer needed, and give each operator only the sites they administer.
- Put backups outside the attack boundary. Store backups off the web server or in a separate account that the site’s runtime user cannot delete. Keep at least one immutable or otherwise protected copy, retain enough history to predate a delayed infection, and test restoration before an incident. A backup that the compromised account can overwrite is not a reliable recovery boundary.
- Document and test the arrangement. Write down the owner of each account, database grant, backup job and recovery credential. Test that Site A cannot list, read or write Site B’s files; that its database user cannot connect to Site B’s database; and that restoring Site A does not overwrite Site B. Re-run these checks after migrations, provider changes and major deployment-tool updates.
How to verify that isolation is real
Perform validation from both the hosting control panel and the application layer. A provider should be able to answer these questions with specific technical details:
- Which Unix user owns and executes each site’s PHP processes?
- Can that user traverse, list, read or write any sibling document root, backup directory or shared temporary directory?
- Does each site have its own PHP worker or pool, and are process environment variables separated?
- Does every site have a distinct database and database user, with no cross-database grants?
- Can a site-level SFTP key or panel sub-user create users, view other accounts or change global settings?
- Are logs and backups readable or deletable by the compromised site’s runtime user?
- Can the provider restore one site without restoring or exposing the others?
Use a disposable test file or staging copy for permission checks, then remove it. Do not probe another customer’s account. If the host cannot explain the boundary or declines to test it, assume the separation is weaker than the marketing description suggests.
Backups, deployment and central management without destroying isolation
Centralized deployment is compatible with isolation when the management plane is more tightly controlled than the sites it manages. Create a separate deployment key or token for each site, scope it to that site’s repository and account, and avoid one superuser credential that can upload to every document root. Keep deployment logs and signing or encryption keys outside the web directories.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Backups need the same discipline. Schedule each site independently, encrypt archives, restrict who can restore them, and keep the storage credentials separate from the WordPress runtime. Test a full restore to a clean account, including database import, file ownership, DNS changes and secret replacement. Record the time required and any manual steps; an untested archive is an assumption, not a recovery plan.
Privilege restrictions should be introduced only when recovery is understood. Before reducing database or filesystem rights, verify that you can restore the site and temporarily elevate access for legitimate updates. This avoids trading a smaller attack surface for an outage that cannot be repaired.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to do when one site is hacked
Isolation limits spread but does not make a compromised site trustworthy. Treat every credential and integration reachable from that site as potentially exposed until reviewed.
- Contain without destroying evidence. Take the affected site out of service or place it behind a maintenance response. Preserve a copy of files, database contents, access logs and timestamps for investigation before deleting or overwriting anything.
- Review every access channel. Examine SFTP and FTP logins, SSH keys, WordPress administrator accounts, the hosting panel, cron jobs, deployment systems, API tokens and MySQL activity. Look for newly created users, changed permissions, unfamiliar scheduled tasks and connections from unexpected addresses.
- Rotate credentials from a clean device. Change hosting-panel, SFTP, SSH, database, WordPress administrator, API and deployment credentials. Replace WordPress salts and invalidate active sessions. Do not reuse the old password on another site.
- Determine the boundary reached. Check whether the compromised Unix user could access sibling files, whether database grants crossed sites, and whether shared backups or secrets were readable. If the boundary is uncertain, assess all sites in that security zone rather than only the visibly altered one.
- Restore or rebuild from known-good material. Prefer a clean, supported WordPress core and verified plugins and themes, then restore content and the database from a backup that predates the compromise. Reapply least-privilege ownership and permissions before reconnecting the site to the network.
- Close the entry point and monitor. Patch the vulnerable component, remove unauthorized persistence, review firewall and server logs, and monitor file integrity and administrator activity after recovery. Keep the preserved evidence until the investigation and any reporting obligations are complete.
Common designs that look isolated but are not
Separate folders under one account
Folders are organization, not an access-control boundary, when the same Unix user owns them. Move to separate users or accounts and verify traversal permissions.
Separate databases with one shared database user
Distinct database names do not help if one credential has grants on all of them. Create a different user and password for every database and remove unused grants.
Read-only core files with writable plugins
Protecting core while leaving plugins, themes or configuration writable still permits persistent code execution. Restrict writes to the smallest required directories and use a controlled deployment process.
Backups stored beside the site
An attacker who can write the document root may find, alter or delete local archives. Keep recovery copies outside the account and maintain an immutable version.
Assuming a premium or managed label guarantees separation
Only the provider’s actual Unix users, process pools, filesystem rules, database grants and panel permissions establish isolation. Obtain those details before migrating valuable sites.
Free tools Windows power users keep installed
One-click scans. No signup required.
How much isolation do you need?
Start with the consequences of a compromise rather than the number of sites. Unrelated businesses, sites holding personal data, stores, membership systems and high-traffic publications justify separate accounts or containers sooner than low-value brochure sites. If a single stolen panel credential would expose every property you operate, the current design has a large avoidable blast radius.
For a small portfolio, one non-privileged user, database and backup set per site on a well-configured server is a meaningful baseline. For higher-risk workloads, use separate accounts or isolated containers and keep management credentials, logs and backups outside each runtime boundary. Separate physical servers provide the clearest fault line but cost the most and still require disciplined credential management.
The practical test is simple: compromise one site in a controlled exercise and ask what it can read, write, execute, authenticate to and delete. Tighten every path that reaches a sibling. Repeat after infrastructure or staffing changes.
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.
