WordPress Keeps Getting Hacked? Cleanup, Hardening and Migration on Shared Hosting

If your WordPress site keeps getting hacked on shared hosting, you are not alone. We see the same pattern again and again: a quick cleanup, the site looks fine for a week or two, and then another wave of spam pages, strange redirects or phishing content appears. The problem is rarely just “one infected file”. On shared hosting, a hacked WordPress is usually the result of a combination of weak passwords, outdated plugins, leftover test installs, and sometimes poor isolation between sites under the same user account. If you only fix the visible symptoms, the attackers come straight back.

In this article, we’ll walk through how we approach recurring WordPress hacks on shared hosting at dchost.com: how to contain the incident, clean it properly, harden WordPress without breaking your workflow, and decide when it is time to migrate to a cleaner environment or a VPS. The goal is simple: instead of living in an endless cleanup loop, you end up with a predictable, maintainable setup that resists the automated attacks hitting the web every day.

Why WordPress Keeps Getting Hacked on Shared Hosting

It’s not (just) you: automated attacks never stop

Most WordPress hacks are not personal. Automated bots constantly scan the internet for known vulnerabilities. Once they find a weak plugin, an exposed admin panel or a file upload bug, they drop malware and move on. If you’re on shared hosting with a popular CMS like WordPress, you’re automatically in their target list.

Common entry points we see in real incidents:

• Outdated plugins or themes with known security bugs
• Nulled (pirated) themes/plugins that ship with backdoors
• Weak admin passwords reused across multiple sites
• Unprotected wp-login.php or XML-RPC allowing brute-force attacks
• Old test/staging installs forgotten under subfolders like /old, /test, /backup

Shared hosting specifics: many sites, one user account

On typical shared hosting, your account may host several WordPress sites under the same cPanel user. Even if each site has its own database, all their files are usually accessible by that one system user. So if one installation gets compromised and the attackers gain file-level access, they often:

• Inject malware into every WordPress installation under that account
• Drop generic backdoors into shared folders such as /tmp or /public_html
• Add cron jobs or hidden PHP scripts that re-infect sites after you “clean” them

This is why recurring hacks are so common on shared hosting. You fix one visible infection, but a hidden door or scheduled task keeps bringing the malware back.

Incomplete cleanups leave backdoors behind

Another big reason hacks keep returning: partial cleanups. Removing the obviously infected file is not enough if you do not:

• Replace all core WordPress files with clean ones
• Scan and clean all plugins and themes (or reinstall them fresh)
• Search the database for malicious scripts and spam content
• Remove malicious users, cron jobs, and hidden backdoor files

Attackers assume cleanups will be rushed. They almost always plant multiple persistence mechanisms. If you don’t remove all of them, the hack repeats.

Step 1: Contain the Incident and Protect Your Accounts

Switch from panic to a checklist

Before touching any files, focus on containment. You want to stop the damage from spreading to more sites, your visitors, or your email reputation.

Immediate actions to take

• Enable maintenance mode or a simple holding page. If the site is serving malware or phishing pages, temporarily put up a static maintenance page while you work.
• Change all critical passwords:
  • WordPress admin accounts
  • cPanel / hosting control panel account
  • FTP / SFTP users
  • Database users for the affected sites
  • Email accounts tied to those domains
• Enable two-factor authentication (2FA) wherever possible, especially for your hosting and WordPress admin accounts.
• Log out all WordPress sessions. Use the “log out of all sessions” option in WordPress profiles or a security plugin to invalidate existing cookies.

Take (and secure) your backups before touching anything

If your hosting account or dchost.com plan keeps automatic backups, confirm that you have at least one clean restore point from before the first hack you noticed. Then:

• Download full backups (files + database) to your local machine
• Keep them read-only and clearly dated for reference

For a deeper strategy beyond this single incident, we recommend adopting the 3‑2‑1 approach covered in our article WordPress backup strategies for shared hosting and VPS. Solid backups turn a stressful cleanup into a recoverable operation.

Check if multiple sites are affected

On shared hosting, do not assume only one WordPress is infected. Quickly:

• List all your domains, subdomains and folders under public_html
• Open their wp-config.php files (if any) to see how many WordPress sites you run
• Look for suspicious files (random names, recent timestamps) in each site’s directory

Even if only one domain is obviously serving spam, treat the entire cPanel account as suspect until proven otherwise.

Step 2: Deep Cleanup – Removing Malware Properly

Decide: repair in place, or rebuild from a clean install?

On recurring hacks, rebuilding from a clean WordPress install is often safer and faster than hunting every single malicious line. A practical approach we often use at dchost.com:

1. Export content (posts, pages, media) and configuration that you trust.
2. Deploy a fresh WordPress with the latest version.
3. Reinstall only the plugins and themes you really need, directly from trusted sources.
4. Import content and reapply settings.

However, if you have a complex site with many customizations, you may need to clean in place. In that case, go methodically.

1. Replace core WordPress files

Start with the easiest and most reliable step:

• Download the latest WordPress package from wordpress.org.
• Via FTP or File Manager, delete all core folders except wp-content and wp-config.php:
  • wp-admin
  • wp-includes
  • All files in the root (like index.php, wp-login.php, etc.) except wp-config.php
• Upload the fresh WordPress files and folders, again without replacing wp-config.php or wp-content.

This step removes many core-level infections and hidden backdoors.

2. Clean or reinstall plugins and themes

Plugins and themes are a primary attack vector. For each site:

• Delete every plugin you are not actively using.
• Delete any nulled or “premium for free” themes and plugins. Replace them with genuine copies or safe alternatives.
• For the rest, it is often safer to delete and reinstall from the official WordPress.org directory or the vendor’s site instead of trying to clean them manually.

After reinstalling, check that you are on the latest version of each plugin and theme. Vulnerability reports are public; attackers follow them closely.

3. Scan and clean the wp-content directory

The wp-content folder holds your uploads, themes, plugins, and sometimes must-use plugins (mu-plugins). Common malware tricks include:

• PHP files hidden under /uploads/ with image-like names
• Backdoors named like core files but placed in unusual folders
• Files with long, random names and recent modification dates

Practical steps:

• Use your panel’s malware scanner (if provided) as a first pass, but do not rely on it alone.
• Sort files by modification time and inspect anything added around the time of the hack.
• Look inside suspicious files for eval(, base64_decode, gzinflate, or heavily obfuscated code.
• Remove any PHP files from /uploads that you did not intentionally place there.

4. Clean the database (hidden scripts and spam content)

Some infections live entirely in the database: injected JavaScript in posts, hidden spam links in wp_options, or malicious shortcodes. To clean this:

• Use phpMyAdmin or another DB tool from your hosting control panel.
• Search in the database for common suspicious patterns like <script>, iframe, strange domains, or known malware signatures.
• Check the wp_options table for unexpected options with long, encoded values.
• Review admin users in the wp_users table and delete any accounts you do not recognize.

After changes, clear any caching layers (plugins or CDN) so you aren’t serving cached malicious content.

5. Remove malicious cron jobs and backdoors

Persistent hacks often rely on scheduled tasks or hidden backdoors to re-infect the site:

• In cPanel or your hosting panel, check Cron Jobs for anything unfamiliar that runs PHP scripts from odd places.
• Search your account (via File Manager or SSH if available) for suspicious PHP files named like wp-*.php, config-*.php, or totally random names.
• Check wp-config.php for extra lines at the very top or bottom that do not belong to the normal configuration.

Only after you’ve done these steps should you bring the site fully back online.

Step 3: Hardening WordPress on Shared Hosting

Secure configuration in wp-config.php

A few simple changes to wp-config.php significantly reduce risk:

• Use strong, unique Authentication Unique Keys and Salts (you can regenerate them from the official WordPress.org salt generator).
• Disable the file editor to stop attackers from using it:

  define('DISALLOW_FILE_EDIT', true);

• Ensure database credentials are strong and unique, not shared with any other app.

File permissions and ownership

On shared hosting, correct file permissions are crucial:

• Folders: typically 755
• Files: typically 644
• wp-config.php can often be tightened to 600 or 640 depending on your host

Many one-click installers or manual uploads end up with overly permissive permissions like 777 on some folders. That’s an invitation for trouble.

Protecting wp-login.php and XML-RPC

Brute-force attacks on the login page and XML-RPC are extremely common. On shared hosting with Apache, you can:

• Use a security plugin to add rate limits, lockouts and CAPTCHAs.
• Restrict access to wp-login.php by IP (via .htaccess) if you have a stable IP.
• Disable or limit XML-RPC if you do not use Jetpack, the mobile app or external publishing tools.

For deeper system-level protections on servers you control, we wrote a dedicated guide on stopping brute-force attacks with Nginx rate limiting and Fail2ban. Even if you stay on shared hosting, the concepts in our playbook for stopping wp-login.php and XML-RPC brute force help you understand what your provider should be doing on the server side.

Use a well-configured security plugin (without slowing the site)

A good security plugin can help with:

• File change monitoring
• Login protection and 2FA
• Basic firewall and known exploit blocking

However, avoid running multiple heavy security plugins at once; they can conflict and slow down your site. Configure a single, well-maintained plugin properly and complement it with server-side measures from your hosting provider.

HTTP security headers and SSL

While not a complete shield against hacking, proper HTTPS and security headers protect your visitors and reduce some attack surfaces. On the hosting side, settings like HSTS, X-Frame-Options and Content-Security-Policy matter. If you want to go deeper, our article friendly guide to HTTP security headers explains how to set these up without breaking your site.

Follow a structured hardening checklist

To avoid missing steps, we recommend going through a full checklist once and then reviewing it periodically. We’ve put together such a list in our article WordPress hardening checklist. Even if you are on shared hosting (and do not control the full server), many of the application-level measures apply directly.

Step 4: Shared Hosting Realities – When the Problem Is Bigger Than One Site

Multiple WordPress installs under one user

One of the most common patterns we see is a single cPanel user hosting:

• The main production site
• Old test versions under subdirectories
• Client projects that were never decommissioned
• Subdomain sites with outdated plugins

Attackers only need one of these to be weak. Once they compromise a vulnerable test site, they can jump to your main domain because the same system user owns the files.

After a hack, consider this non-negotiable:

• Remove old, unused WordPress installs completely.
• At minimum, update and harden every remaining site under that account.

Check your hosting panel’s security features

Modern shared hosting (including our shared plans at dchost.com) usually includes at least some of the following:

• Built-in malware scanning
• WAF (Web Application Firewall) rules tuned for WordPress
• Rate limiting and brute-force protection on common endpoints
• Isolation between accounts at the system level

If you are repeatedly getting hacked despite cleaning and hardening your site, it’s worth discussing with support what protections are in place on the server. Our cPanel security hardening checklist gives you an idea of what a well-hardened hosting environment should look like.

DNS, domain and email implications

Repeated hacks can damage more than your website. If attackers send spam or host phishing pages under your domain, email providers and security tools may start to distrust your domain. Over time, this can affect deliverability and brand reputation. For a broader view of domain-side security, see our guide on domain security best practices (registrar lock, DNSSEC, WHOIS privacy and 2FA).

Step 5: When (and How) to Migrate for Better Security

Signs that your current shared hosting setup is holding you back

Staying on shared hosting can be perfectly fine if your provider keeps the platform updated and you maintain your WordPress properly. But there are clear red flags:

• Repeated hacks despite cleaning, updating and hardening your site
• No reliable backups or restore tools in the control panel
• No clear information about server-side security or isolation
• Performance issues after enabling basic security and caching

In these cases, moving to a better-secured shared plan or to a VPS where you have more control over the environment can significantly reduce your risk and give you room to implement stronger protections.

Migrating between shared hosting providers or plans

If you are moving from one cPanel-based shared hosting environment to another (for example, into a hardened environment at dchost.com), the migration can usually be done with near zero downtime. We recommend:

• Planning your DNS TTL changes in advance so that the switchover is quick.
• Using account-level transfers or full backups rather than manual partial moves.
• Performing at least one test restore on the new platform before cutting over traffic.

We describe this process step-by-step in our zero‑downtime cPanel‑to‑cPanel migration playbook. The same principles apply whether you are changing regions, providers or plans.

When to move from shared hosting to a VPS

If your site is important to your business, security incidents are recurring, and you are hitting the limits of what can be done on shared hosting, a VPS becomes very attractive. With a VPS from dchost.com, you can:

• Isolate each WordPress site under its own system user
• Deploy custom WAF rules tuned to your traffic
• Use advanced tools like Fail2ban, system firewalls, and intrusion detection
• Fine-tune PHP, database and caching for performance and security

The move does not have to be painful. We’ve documented a practical path in our guide to moving from shared hosting to a VPS with zero downtime. Even if you are not ready to move today, reading through that checklist will help you plan ahead.

Use staging for safe updates and testing

Many hacks exploit outdated components that site owners are afraid to update because “something might break”. A staging environment solves that problem. You clone your live site to a separate subdomain, apply updates and test, then push the changes to production once you are confident.

On cPanel-based hosting (including dchost.com), you can set up a staging environment relatively easily. Our step-by-step article how to create a WordPress staging environment on cPanel walks you through subdomain creation, cloning, and safe go-live workflows.

Step 6: Long-Term Hygiene – Staying Clean After the Hack

Build an update habit

Security is not a one-time project. To avoid repeating this experience:

• Schedule a monthly maintenance window for updates.
• Update WordPress core, plugins and themes during that window.
• Remove plugins and themes you no longer use instead of letting them sit outdated.

If you use staging (as described above), this becomes a low‑stress routine instead of a risky event.

Minimalism: fewer plugins, fewer problems

Every plugin is another potential vulnerability. We regularly see sites with 30–50 plugins installed, many of them doing overlapping jobs. Over time:

• Audit your plugins and remove those that are redundant or rarely used.
• Prefer well-known, actively maintained plugins with transparent changelogs.
• Avoid “all‑in‑one miracle” plugins from unknown vendors.

Monitor logs and anomalies

On shared hosting, you may not have full system logs, but you usually have:

• Access logs for your domains
• Error logs for PHP and Apache
• Security plugin logs (login attempts, file changes)

Set a simple habit: after monthly updates, quickly scan logs for unusual spikes in 404s, suspicious user agents or repeated attempts on wp-login.php. The earlier you detect a pattern, the easier it is to respond.

Use a CDN/WAF layer if appropriate

A CDN with a Web Application Firewall in front of your site can block a good portion of generic attacks before they even hit your hosting account. This is especially helpful on shared hosting where server-level tuning is limited. Combined with the hardening steps we discussed above, it adds another layer attackers must get through.

Review hosting and domain settings annually

Once a year, take a broader look at your setup:

• Are you still on a plan and platform that fits your traffic and risk profile?
• Is your domain secured with registrar lock and 2FA?
• Is your SSL/TLS configuration up to date and free from old protocols?
• Do you have a written, simple recovery plan if something goes wrong?

Our team at dchost.com builds these reviews into many of the projects we work on, because they catch “slow‑burn” risks that individual incidents never reveal.

Conclusion: From Endless Cleanups to a Calm, Secure Routine

If your WordPress site keeps getting hacked on shared hosting, it is rarely because of one unlucky incident. It is almost always a mix of outdated components, weak access controls, leftover test installs, and sometimes a hosting environment that is not doing enough on the server side. The good news is that you can break the cycle. A structured cleanup, followed by solid hardening and a realistic migration plan if needed, turns recurring disasters into a manageable maintenance routine.

Start by containing the current incident, then clean thoroughly: core files, plugins, themes, uploads, database, cron jobs and backdoors. Harden your configuration with better passwords, proper file permissions, login protections and HTTP security headers. From there, decide whether staying on your current shared hosting is still the right move or whether a hardened shared plan or a VPS at dchost.com would give you the isolation and control you need. If you want help planning that journey, our team is here to assist with migration, security reviews and ongoing hosting that is built with WordPress in mind.