WordPress Keeps Getting Hacked: Cleanup and Prevention

If your WordPress site keeps getting hacked on shared hosting, investigate what survived the previous cleanup and how access was regained. Spam pages, redirects or phishing content may return because of an unresolved vulnerability, stolen credentials, a retained backdoor or another accessible installation. Fixing a visible file does not establish that the account is clean.

This guide covers containment, evidence preservation, cleanup, hardening and the decision to rebuild or migrate. It applies to WordPress on shared hosting and helps assess whether a VPS or another environment is justified. The objective is a recoverable, maintainable system with an identified operator for each task; changing hosting alone does not fix a vulnerable application.

Why WordPress Keeps Getting Hacked on Shared Hosting

Automated attacks and exposed vulnerabilities

Automated scanners look for known vulnerabilities and weak authentication on publicly reachable sites. A vulnerable plugin, an unsafe upload handler or stolen credentials can provide access. A public login page is not itself proof of a vulnerability, and repeated requests are not proof of a successful compromise. Use logs and confirmed changes to distinguish attempts from actual access.

Common entry points and risk factors:

• Outdated plugins or themes with known security bugs.
• Nulled themes or plugins that may contain modified code or backdoors.
• Weak, reused or stolen credentials for WordPress, hosting or connected services.
• Insufficient login protection on wp-login.php or XML-RPC where password attacks can reach authentication.
• Old test/staging installs forgotten under folders such as /old, /test or /backup.

Shared hosting specifics: many sites, one user account

Several sites under one cPanel account may share a system user and access permissions even when their databases differ. If compromised code can read or write another installation, it may reach that site’s files and credentials. Inspect the actual ownership and access boundaries; a compromise does not automatically cross properly isolated hosting accounts. Within accessible paths an attacker may:

• Inject malware into other accessible WordPress installations 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 one way a site can be reinfected 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 altered WordPress core files from trusted packages and inspect extra files separately.
• Review or reinstall plugins and themes, including custom code and dependencies.
• Inspect uploads, database content and configuration for unauthorized changes.
• Remove confirmed malicious users, scheduled tasks and backdoors across all affected installations.
• Close the original entry point and revoke exposed access credentials.

Attackers can plant multiple persistence mechanisms. Any that survive cleanup can allow reinfection.

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

• Restrict access to affected sites. Coordinate containment with the host and serve a separate static holding page if needed. A maintenance plugin or changed homepage does not stop direct access to infected scripts, other URLs or background tasks.
• Secure access from a trusted, updated device. Start with hosting and recovery email accounts. Rotate affected WordPress, panel, SFTP/FTP, database and connected-service credentials; update each application’s database connection settings when changing its database password. Repeat rotation after cleanup for secrets exposed during the work.
• Revoke existing access. Cover sessions for all WordPress users and review application passwords, hosting sessions, SSH keys, API tokens and additional transfer accounts separately. A WordPress cookie reset does not revoke these other credentials.
• Enable supported two-factor authentication. Store recovery access securely and retain a tested way to administer the contained system.

Take (and secure) your backups before cleanup

If the plan or your own backup system retains earlier copies, identify a candidate from before the earliest known compromise. A backup predating visible symptoms may still be infected. Inspect it and test recovery in an isolated environment before treating it as a clean restore point. Before destructive cleanup:

• Preserve a snapshot of the current files, database and available access, error and security logs. Record timestamps and the actions already taken.
• Keep the incident copy outside publicly accessible paths in protected storage; label it as potentially infected and do not execute its code.
• Keep verified recovery backups separate from incident evidence. Protect both against unauthorized alteration and access because they may contain credentials and personal data.

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 domains, subdomains, document roots and old installations, including paths outside public_html.
• Inspect relevant wp-config.php files as text to map installations and database dependencies; do not execute suspicious copies.
• Review file changes and access logs across each site. Random names and recent timestamps are clues, not proof; timestamps can be modified.

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?

Choose between a controlled in-place repair, a verified clean backup and a fresh installation based on the scope you can investigate. A clean rebuild can be preferable when persistence is widespread or the history is uncertain. It still requires reviewed data, secure access and closure of the entry point:

1. Preserve incident evidence and review exported posts, pages, media, users and configuration for malicious additions.
2. Deploy a fresh, supported WordPress installation in a clean environment isolated from the compromised account.
3. Install necessary themes and plugins from official sources; review custom development separately.
4. Import only reviewed data and media, create fresh credentials and keys, resolve the entry point and verify both security and application behavior before reopening.

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

Preserve the incident snapshot and verify the installation path and version before removing anything. Core replacement is one part of cleanup:

• Obtain the official package for the installed version when performing a like-for-like core repair; plan and test an upgrade to a supported current release before reopening.
• Use SFTP or a trusted File Manager to replace the core directories wp-admin and wp-includes with clean copies. Retain wp-content and wp-config.php for separate inspection.
• Replace WordPress core files in the installation root, including index.php and wp-login.php, using the package inventory. Exclude wp-config.php from blind replacement.
• Inventory non-core and hidden files separately. Preserve legitimate site-specific configuration and remove confirmed malicious additions; copying over a directory does not remove extra files. Do not replace wp-config.php or wp-content with unreviewed backup copies.

This removes infections only from the files actually replaced. Inspect wp-config.php, retained hosting configuration and other files independently. Core checksums or an apparently working homepage are not evidence that the whole account is clean.

2. Clean or reinstall plugins and themes

Review plugins, themes and custom development against trusted packages and documented local changes:

• Remove unused plugins and themes after preserving data and checking dependencies; uninstall behavior can delete settings or application records.
• Remove nulled packages and use genuine releases or suitable maintained alternatives.
• Reinstall required components from WordPress.org or their official vendor. Review custom code separately. A clean package copied over an infected folder may leave extra malicious files, so account for those additions during replacement.

After reinstalling, check that you are on the latest version of each plugin and theme. Check public vulnerability reports and vendor advisories too; the latest release may still have an unresolved vulnerability. Remove or replace components with unresolved security issues.

3. Scan and clean the wp-content directory

The wp-content folder contains uploads, themes, plugins and possibly must-use plugins (mu-plugins). Must-use plugins load separately from the ordinary active-plugin list. Also inspect drop-ins such as advanced-cache.php, object-cache.php and db.php, comparing them with their legitimate provider or developer source. Their existence alone does not indicate malware. Clues to investigate 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, but do not limit the review to recent files; timestamps can be altered.
• Look inside suspicious files for eval(, base64_decode, gzinflate, or heavily obfuscated code. These are clues, not proof of malware; review their context before deleting anything.
• Investigate unexpected PHP files under /uploads. Check whether legitimate software created them, and quarantine confirmed malicious files outside the web root.

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

Database changes can include injected JavaScript in posts, spam links or altered settings in wp_options, and unauthorized users. Their effect depends on how the application reads them; an encoded value or a script tag is not automatically malicious. Preserve the database snapshot before editing:

• Use a trusted database or administration tool and the installation’s actual table prefix; wp_options and wp_users are examples.
• Investigate suspicious <script>, iframe, domains or signatures in context. Do not delete all matching values.
• Review options, posts, widgets and application-specific tables. Do not limit the investigation to long, encoded or autoloaded values; preserve serialized-data structure and application dependencies during corrections.
• Check users and role/capability records in the corresponding usermeta table, including network privileges if Multisite is used. Confirm account ownership and authorization before removal. Use a trusted management path and preserve legitimate content ownership rather than deleting arbitrary database rows.

After cleaning the origin and verifying the changes, invalidate affected application and CDN caches so that old malicious responses are no longer served. Test the relevant URLs and user journeys; a cache purge cannot clean infected source files or database content.

5. Remove malicious cron jobs and backdoors

Review persistence across the account, including code outside the normal plugin list and scheduled work:

• Inspect panel cron jobs and WordPress scheduled events, including the files or callbacks they invoke. Remove confirmed unauthorized tasks together with their malicious payloads; do not delete unfamiliar legitimate jobs blindly.
• Search authorized account paths for unexpected files, including names like wp-*.php or config-*.php, but do not rely on filename patterns alone.
• Read the entire wp-config.php as text, including unexpected includes or executable statements, not only its first and last lines.
• Inspect .htaccess and .user.ini in applicable account, site and subdirectories for unauthorized redirects, handler changes and auto_prepend_file settings. Confirm legitimate host configuration before modifying it.
• Repeat the investigation across other sites, abandoned installs and staging copies sharing access. Ask the provider to investigate system settings outside your permissions.

Reopen only after resolving the identified entry points, reviewing persistence and credentials, and checking the cleaned application in isolation. If malicious files keep returning or the compromise scope remains unclear, retain containment and seek qualified help. Passing functional tests alone does not prove the absence of malware.

Step 3: Hardening WordPress on Shared Hosting

Secure configuration in wp-config.php

After reviewing wp-config.php for injected code, check these controls and their limits:

• Generate fresh, unique authentication keys and salts from the official WordPress generator. Replacing them invalidates WordPress login cookies; revoke application passwords, SSH keys and other access separately.
• Disable the dashboard file editor with the existing configuration statement:

  define('DISALLOW_FILE_EDIT', true);

  This removes the theme/plugin editing capability in the dashboard. It does not prevent every file write, plugin installation or exploit.

• Use strong database credentials and separate application database users with appropriate privileges. Coordinate password changes with connection settings and check update/backup requirements before restricting privileges.

File permissions and ownership

Choose permissions together with file ownership, the PHP execution user and the host’s supported configuration:

• 755 for directories and 644 for files are common starting values, not universal requirements.
• For wp-config.php, a more restrictive mode such as 600 or 640 may fit the ownership model; verify that the application can still read it.
• Limit write access to the users and paths that need it. Confirm updates, uploads, backups and deployment still function before applying broad changes.

Avoid unnecessary world-writable permissions such as 777. Do not recursively change the whole hosting account without understanding ownership and dependencies. Restrictive modes cannot isolate sites from each other if the same compromised user legitimately owns and can modify both.

Protecting wp-login.php and XML-RPC

Reduce password attacks using controls supported by the actual web server and application:

• Use maintained login controls for rate limits, lockouts and supported 2FA; test legitimate user access and recovery.
• Restrict wp-login.php by IP only where stable access and the actual server support it; .htaccess rules require an applicable Apache configuration. Keep a recovery route.
• Limit or disable XML-RPC only after checking Jetpack, mobile apps and external publishing dependencies.
• Where traffic passes through a proxy or CDN, configure trusted client-IP handling so limits act on the intended visitor rather than a shared proxy address.

The wp-login.php and XML-RPC brute-force guide covers Nginx rate limiting and Fail2ban for environments where you control those services. Shared-hosting users should confirm available server-side controls with the provider. These controls complement updates and credential security; they do not repair a compromised application.

Select and test a security plugin

A good security plugin can help with:

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

Choose a maintained plugin for the required features and test its configuration, alerts and performance. Overlapping plugins can conflict. A scanner may miss malware, and a plugin firewall runs within the application’s own trust boundary; combine it with appropriate host controls rather than treating it as proof of cleanup.

HTTP security headers and SSL

HTTPS protects data in transit; it does not remove malicious code or fix injection vulnerabilities. HSTS, framing controls and Content-Security-Policy provide different protections and require application testing. Stage restrictive policies, confirm subdomain and embedding needs, and avoid rushed HSTS preload changes. The HTTP security headers guide explains these controls and deployment considerations.

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: Check the Wider Hosting Account

Multiple WordPress installs under one user

An account inventory may reveal several independently maintained installations:

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

A vulnerable test site can expose the main site if their file permissions, credentials or shared user allow it. Inspect the actual access boundary instead of assuming either complete isolation or automatic compromise of every hosting account on the server.

Reduce unnecessary exposed installations after checking their owners and dependencies:

• Retire unused installations through a controlled process: preserve needed records, check linked services and remove the old web-accessible copy.
• Update and harden all retained sites, including staging; document ownership and maintenance responsibility.
• Where isolation is required, verify separate execution users and access restrictions. Separate databases alone do not isolate files shared by one user.

Check your hosting panel’s security features

Ask your provider which protections are active on the selected plan, what they cover and who responds to an alert. Do not assume that the following are included:

• Malware scanning, its scope and any separate cleanup service.
• WAF rules and control over exceptions or false positives.
• Rate limits and login protection on relevant endpoints.
• Isolation between system accounts, distinct from separation between sites inside one account.
• Backup retention, restore access and incident-response responsibilities.

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

Phishing pages or spam sent through a compromised site can affect visitor warnings, email delivery and reputation. Investigate unauthorized DNS, registrar and mail-account changes as part of the incident. The domain security guide covers registrar access, locks and DNSSEC. Those measures have separate roles; neither DNSSEC nor registration privacy cleans website malware. If Search Console reports security issues, follow its issue-specific investigation and request-review process after fixing all affected pages. Review does not guarantee immediate removal of warnings.

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

These findings justify reviewing the platform and operating model, but a slower site or repeated infection does not establish that the host caused the compromise. Resolve application and account problems first. If verified isolation, control or capacity needs exceed the current service, compare a suitable shared plan, managed service or VPS together with the skills and responsibilities required.

Migrating between shared hosting providers or plans

A hosting migration during incident recovery must keep unreviewed code and credentials out of the destination. Confirm the service scope and migration method with the provider. Downtime and data consistency depend on the application and cutover process:

• Inspect and clean data, users, configuration and media before transfer. A full account backup or account-transfer tool can also copy malware, cron jobs and stolen credentials.
• Prepare the destination independently with trusted software and fresh access credentials; test it under restricted access before changing traffic.
• Plan DNS TTL changes at least the previous TTL in advance where possible; a lower TTL does not invalidate old cached answers.
• Define the final write freeze or synchronization, order/session consistency and rollback boundary. Keep required services consistent during DNS overlap, and do not reopen an infected old site merely to reduce downtime.

The cPanel-to-cPanel migration guide provides transfer and DNS planning context. Its historical zero-downtime wording is not a guarantee for a compromised installation. Choose the recovery method and acceptable interruption based on clean-state verification and data preservation.

When to move from shared hosting to a VPS

A VPS can provide more configuration control if the plan grants the required administration access. It is not inherently secure: the operator must configure site isolation, patch the OS and applications, monitor incidents and test backups. DCHost or another provider’s server offering does not imply included WordPress cleanup or managed administration. With appropriate access and expertise, options include:

• 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 shared-hosting-to-VPS migration checklist helps plan DNS, certificates, email and application testing. Verify the specific plan’s management scope, lead time and rollback path. Moving the same vulnerable code to a larger server does not resolve the entry point.

Use isolated staging for updates and recovery tests

Staging lets you check application changes before production, but it is not automatically a safe place to execute a compromised clone. For recovery, build a clean environment with restricted access and import reviewed material. Isolate any suspicious copy from public traffic and production credentials. Disable or substitute real payments, email, webhooks and scheduled external actions during tests; use access control, not only a noindex setting.

The cPanel WordPress staging guide describes one possible setup where the panel and plan permit it. Test login, forms, orders, scheduled jobs and updates using controlled services. Plan deployment and final data synchronization explicitly; blindly copying the staging database over production can erase new transactions.

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:

• Monitor security advisories and apply security updates promptly according to exposure and severity; do not wait for a monthly window to close an actively exploited issue.
• Use routine maintenance windows for nonurgent updates, dependency review and recovery checks. Test compatibility and retain a rollback route.
• Enable supported automatic security updates where appropriate and monitor their success. Retire unused components after checking dependencies.

Staging, backups and rollback reduce change risk when they are maintained and tested. They do not justify leaving an exposed known vulnerability unresolved while waiting indefinitely for a convenient window.

Keep a maintained component inventory

Every component adds code and maintenance responsibilities. Plugin count alone does not measure security; assess necessity, update history, current advisories and overlap:

• Record each required plugin/theme, its owner and its update source; remove redundant components only after checking dependencies and data.
• Prefer maintained software with clear release and security information. Popularity alone is not a security guarantee.
• Track custom code, must-use plugins and drop-ins as well as ordinary plugins; they may need separate update procedures.

Monitor logs and anomalies

Confirm which logs your plan exposes, their retention and export options. Depending on the platform, useful sources include:

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

Monitor relevant alerts continuously where supported and review logs at a frequency suited to the risk, with closer observation after recovery. Investigate unexpected file changes, new privileged accounts, scheduled tasks and unusual authentication or outbound activity. A spike in 404s or requests to wp-login.php can be a clue, not proof of compromise. Name an operator and escalation route; a monthly glance alone can leave a recurrence undetected.

Use a CDN/WAF layer if appropriate

A CDN/WAF can filter some application attacks when correctly configured. Confirm that intended traffic passes through it, restrict direct origin access where practical, and maintain trusted-proxy/client-IP settings. Test false positives against login, forms and payments. It complements cleanup and patching; it does not guarantee that vulnerabilities cannot be exploited. Network-level DDoS protection and upstream capacity require a separate provider discussion.

Review hosting and domain settings annually

Review the broader plan at least annually and after material changes or incidents; routine patching, alerts, certificate renewal and access revocation require their own shorter schedules:

• 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?

Assign owners for access, updates, backup restoration, alerts and incident response. Confirm any assistance, response targets and fees in the provider’s agreed service scope. A product catalogue is not evidence that malware cleanup or ongoing security review is included.

A Recovery Checklist for Recurring WordPress Hacks

Recurring compromise calls for an account-wide investigation: contain access, preserve evidence, review core files, plugins, themes, uploads, database content, configuration and scheduled work, and examine every installation sharing access. Resolve the entry point and revoke exposed credentials. Choose a clean rebuild or verified backup when the current installation cannot be reliably reviewed.

Before reopening, verify the cleaned application, update supported components and check access boundaries. Continue monitoring afterward and address any Search Console security report through its review process. Consider a different hosting arrangement when confirmed resource, isolation or management needs justify it, and clarify the work each party will perform. The outcome should be a recovery and maintenance plan with named owners and tested restore procedures, without promises of perfect security or an interruption-free migration.