A large share of the WordPress sites I clean up after hacks are on shared hosting. That’s not because shared hosting is inherently insecure. Plenty of shared hosts do a good job. It’s because shared hosting is where most small sites live, and because of one specific problem I see again and again: one site gets infected, and the infection spreads to every other site in the same account.
I’ve cleaned accounts where a forgotten test install from years ago was the entry point, and the malware then spread to the owner’s main business site, their partner’s portfolio and a client site they’d set up as a favour. Cleaning the main site alone was pointless, because the other infected sites reinfected it within days.
If you run WordPress on shared hosting, understanding how this happens is the first step to preventing it.
How shared hosting works
On shared hosting, many customers share one server. The host separates customers from each other, usually by running each account under its own system user. Within your account, though, every site you host typically runs as the same user and can read and write every other site’s files.
That’s the key point. The isolation that protects you from other customers usually doesn’t exist between your own sites in the same account.
How cross-site contamination happens
- An attacker compromises one site in the account, often an outdated or forgotten installation.
- Their malicious code runs as the account’s user.
- That user can write to every other site’s files in the account.
- The malware copies itself into other sites, adds backdoors and modifies core files.
- You clean the site you noticed, but backdoors in the others reinfect it.
Malware authors know this pattern well. Many backdoors I find include code specifically designed to search the account’s home directory for other WordPress installations and infect them.
Step 1: Inventory everything in your account
Log in to your hosting control panel or SFTP and look at every folder. You may find:
- Old test installations.
- Staging copies.
- Abandoned projects.
- Sites you set up for friends or clients.
- Backup archives and old copies of sites.
Every WordPress installation is a potential entry point. Old ones with outdated plugins are the most dangerous.
Step 2: Remove what you don’t need
Delete installations you no longer use, including their databases. If you might need them later, download a backup to your own computer or offline storage first, then remove them from the server.
Remove old backup archives from the web root too. Downloadable backups expose your database and configuration to anyone who guesses the filename.
Step 3: Separate important sites
Ideally, each important site should have its own hosting account, or at least its own isolated user. Options include:
- Separate shared hosting accounts for business-critical sites.
- Hosting plans that run each site under its own system user.
- Moving important sites to managed WordPress hosting or a VPS with proper isolation.
The cost of a second hosting account is small compared with the cost of cleaning up a multi-site infection.
Step 4: Keep every site updated
If you keep several sites in one account, all of them need to be maintained, not just the main one. The weakest site in the account sets the security level for all of them.
- Update WordPress, plugins and themes on every site.
- Remove unused plugins and themes everywhere.
- Use strong, unique passwords for every admin account on every site.
Step 5: Use correct file permissions
On shared hosting, typical safe permissions are:
- Directories: 755.
- Files: 644.
- wp-config.php: as restrictive as your host allows, often 400, 440 or 600.
Never use 777. If something isn’t working and the suggested fix is 777, find out what’s really wrong instead. On some shared hosts, overly permissive files can be accessible to other customers on the same server, and some hosts block PHP files with unsafe permissions altogether.
Step 6: Protect wp-config.php
wp-config.php contains your database credentials. Beyond restrictive permissions:
- Some hosts let you move wp-config.php one directory above the web root, and WordPress will still find it.
- Use a unique database user for each site, with access only to that site’s database. If one site is compromised, the attacker can’t read other sites’ databases using its credentials.
- Use strong database passwords.
Step 7: Block PHP in uploads
On Apache-based shared hosting, add an .htaccess file in wp-content/uploads to stop PHP files from running:
| <code><FilesMatch "\.(php | phtml | php5 | php7 | phar)$"> |
|---|
Many hosts support this. It stops one of the most common backdoor techniques, even if an attacker manages to upload a file.
Step 8: Disable file editing
Add this to wp-config.php on every site:
It removes the theme and plugin editor from the dashboard, a favourite tool for attackers with stolen admin passwords.
Step 9: Use the host’s security features
Many shared hosts offer:
- Malware scanning.
- Web application firewalls.
- Automatic backups.
- PHP version selection.
- Two-factor authentication for the control panel.
Turn on what’s available, and check how backups work: how often, how long they’re kept and how to restore.
Step 10: Keep your own backups
Host backups are useful, but they often live on the same infrastructure and may only be kept for a short time. Keep your own off-site backups for important sites, with enough history to restore from before an infection that went unnoticed for weeks.
Step 11: Protect the hosting account itself
The control panel, SFTP and email accounts for your hosting are as important as WordPress admin accounts:
- Use strong, unique passwords.
- Enable two-factor authentication if available.
- Use SFTP rather than plain FTP.
- Remove old FTP accounts created for developers who no longer need them.
Cleaning up a contaminated account
If one site in your account is infected, assume all of them may be. A proper cleanup:
- Back up the account in its current state, for evidence.
- Identify every WordPress installation in the account.
- Scan all of them, not just the one you noticed.
- Clean every infected site, replacing core, plugins and themes with fresh copies.
- Remove unknown files from the account’s home directory, not just inside site folders. Malware sometimes hides outside public folders.
- Check cron jobs in the control panel for malicious scheduled tasks.
- Change all passwords: control panel, SFTP, databases and WordPress admins for every site.
- Regenerate security keys in each wp-config.php.
- Find and fix the original entry point.
Cleaning sites one at a time while others remain infected leads to endless reinfection.
When to move off shared hosting
Shared hosting is fine for many small sites. Consider moving when:
- The site generates significant revenue, especially a store.
- You need more control over server configuration and security.
- You host many sites and want proper isolation between them.
- Performance suffers because of shared resources.
- Your host’s security support is weak.
Managed WordPress hosting or a well-maintained VPS gives each site better isolation and lets you apply stronger protections.
Choosing a better shared host
If you stay on shared hosting, choose a host that:
- Isolates each site or account properly.
- Supports current PHP versions.
- Offers server-level malware scanning and a firewall.
- Provides reliable backups with reasonable retention.
- Offers SFTP and SSH access, and two-factor authentication.
- Has responsive support that understands WordPress.
Shared hosting can be perfectly safe when every site in the account is treated as part of the same security boundary.
Frequently asked questions
Is shared hosting safe for WordPress?
It can be, if the host provides good isolation and you keep every site updated. The biggest risk is usually keeping several sites in one account, where one infected site can affect the others.
Can other customers on the server hack my site?
Good hosts isolate customers from each other, so this is uncommon. The more common problem is contamination between your own sites in the same account.
Why does my site keep getting reinfected?
Often because another site in the same account, or a backdoor outside the site folder, is still infected. Clean everything in the account and fix the entry point.
Should every site have its own hosting account?
Important sites should be isolated, either with separate accounts or hosting that runs each site under its own user. Small test sites should be removed when no longer needed.
Final thoughts
On shared hosting, your sites are often only as secure as the weakest one in your account. Inventory and remove old installations, isolate important sites, keep every site updated, use correct permissions and unique database users, block PHP in uploads, protect the hosting account and keep your own backups. If an infection happens, clean the whole account, not just the site you noticed. These steps turn shared hosting from a liability into a perfectly reasonable home for a small WordPress site.
