WordPress Malware Removal: Quick Step-by-Step Guide

Your WordPress site has been infected with malware. Your hosting provider flagged it, your users are seeing warnings, or your site simply vanished offline. The panic is real—but the fix is methodical. Malware removal isn't about panic-deleting files; it's about systematic isolation, forensic inspection, and complete restoration. In this guide, I'll walk you through the exact steps HostWP uses to clean compromised sites, and how to prevent it happening again.

Malware infections are one of the top 10 reasons SA WordPress sites go offline. Between load shedding disruptions, inadequate backup routines, and shared hosting environments, many South African businesses are running WordPress on infrastructure that doesn't isolate threats effectively. At HostWP, we've recovered over 150 SA sites from malware infections in the past 18 months alone—and the common thread is always this: site owners delayed action. The longer malware sits active, the deeper it buries itself.

Step 1: Detect and Isolate the Threat

The first 30 minutes are critical—your site must be taken offline immediately to prevent further infection spread and to stop attackers from harvesting user data. Don't debate this step.

Here's what isolation looks like: If you have administrative access, log into WordPress and navigate to Settings → Reading. Set your site to "Discourage search engines from indexing this site" and add a maintenance notice. Better yet, if you use Cloudflare (which is included free with HostWP WordPress plans), activate a temporary "Under Maintenance" page via a page rule. This prevents users from landing on infected pages while you work.

Next, disable all plugins: go to Plugins → Installed Plugins and deactivate (don't delete yet) every plugin. Malware often hides inside plugin code or uses plugins as a vector. Switching to a default WordPress theme (like Twenty Twenty-Three) is equally important—custom themes can contain injected code. Take a screenshot of which plugins were active; you'll need this list for forensics.

Now, change your WordPress admin password—immediately. If the attacker has credentials, they can re-infect even after cleaning. Use a password manager and generate a 32-character random password. If you're running WordPress multisite or have multiple administrators, reset all of them.

Faiq, Technical Support Lead at HostWP: "The moment we detect malware, we isolate the site from the network layer—not just WordPress settings. We pause live traffic, enable read-only filesystem mode if possible, and then conduct forensics offline. In South Africa, where many sites are on shared hosting through competitors like Xneelo or Afrihost, isolation is harder because one infected site can trigger an entire server suspension. That's why managed WordPress hosting with real isolation (like our LiteSpeed + Redis infrastructure in Johannesburg) prevents lateral spread."

Step 2: Access Your Files and Database Safely

Malware removal requires direct file and database access—WordPress admin panels often can't see hidden files or core-level backdoors. You'll need SFTP (secure file transfer) and a database client like phpMyAdmin or command-line MySQL access.

Via SFTP (use FileZilla or similar), connect to your hosting account and download a complete backup of your /wp-content and /wp-includes directories to your local machine. Don't attempt removal via the web interface yet. Create a timestamped folder (e.g., site_backup_2025_01_22) and store these files offline. This gives you a forensic copy if something goes wrong.

In your root directory, look for suspicious files or folders:

• Hidden files starting with a dot (`.htaccess`, `.user.ini`) that you didn't create
• New PHP files in unexpected locations (e.g., wp-admin/temp.php, uploads/shell.php)
• Recently modified files (check timestamps)

Most shared hosting platforms in South Africa (cPanel, Plesk) allow file modification date sorting. Any core WordPress file modified outside of official updates is suspicious. Document the filenames—you'll compare them against known-clean versions later.

For database access, export a backup via phpMyAdmin and save it locally as well. Then, inside phpMyAdmin, navigate to the wp_users table and inspect user accounts. Legitimate users should match your admin roster. Malware often creates fake admin accounts; delete any you don't recognize. Check the wp_options table for suspicious entries under keys like `siteurl`, `home`, or custom ones starting with unusual prefixes.

Step 3: Run Security Scans and Manual Inspection

Now activate industry-standard security scanners. The two most reliable for offline + online inspection are Wordfence and Sucuri. Both offer free tiers; Wordfence's Endpoint Firewall is particularly good at catching backdoors.

Install Wordfence fresh: via SFTP, upload a clean copy of Wordfence's core plugin files directly to /wp-content/plugins/wordfence (don't download via WordPress admin—use the GitHub release). Log in and run a full scan. Wordfence will flag malicious code signatures, suspicious plugins, and shell files. Take screenshots of findings.

Run Sucuri's free online scanner (sucuri.net/website-security-scanner) separately. It scans your live site from their servers and cross-references against malware databases. Sucuri is excellent at identifying injected payloads in database options and known C2 (command-and-control) callback domains.

For manual inspection: use grep or a text editor to search suspicious code patterns across all PHP files. Common malware signatures include:

• eval( or base64_decode( in non-core files
• system(, exec(, or passthru( functions
• Obfuscated PHP (long strings of encoded characters)
• Files with names like `wp-load-old.php`, `config.php.bak`, or `index-backup.php`

Step 4: Remove Backdoors and Malicious Code

Deleting files is only 30% of malware removal. Sophisticated attacks leave backdoors—hidden entry points that re-infect the site within hours or days. This is why casual removal often fails.

Start with plugin removal. Go through your plugins list systematically. Delete any:

• You didn't install or recognize
• Flagged by Wordfence or Sucuri
• With unusual author names or from unknown sources
• That were active at the time of infection

Via SFTP, manually delete the folder (e.g., `/wp-content/plugins/suspicious-plugin`) rather than via WordPress admin. Malware-infected plugins sometimes prevent deletion through the dashboard.

For theme removal, delete the custom theme you were running (via SFTP: `/wp-content/themes/your-theme`). Only keep WordPress's bundled themes (Twenty Twenty-Three, etc.). Even if your theme seems clean, assume it was the infection vector.

Now, inspect the `/wp-content/uploads` directory—malware often hides shell scripts here disguised as images. Look for PHP files in this folder (there should be none). Delete any you find. Check for subdirectories you don't recognize.

In your WordPress root directory, examine these critical files for injected code:

• wp-config.php – check for extra database credentials or backdoor connections
• .htaccess – look for rewrite rules you didn't create (common malware tactics redirect traffic)
• index.php – should be standard WordPress, no extra code

If you find injected code, replace these files with clean copies from wordpress.org (download the exact version your site uses, then extract and copy only these files). Never hand-edit wp-config.php unless absolutely necessary.

Step 5: Audit and Clean Your Database

Database infections are harder to spot but critical to clean. Malware injects malicious content into post content, post metadata, and plugin options. This is where backdoors hide.

In phpMyAdmin, run this SQL query to find suspicious posts:
SELECT * FROM wp_posts WHERE post_content LIKE '%eval(%' OR post_content LIKE '%base64_decode%';

Any results are infected posts. Delete them (or restore them from your backup using clean content). Repeat with the post_excerpt and post_title columns.

For postmeta and usermeta, check for entries with suspicious serialized data:
SELECT * FROM wp_postmeta WHERE meta_value LIKE '%eval(%';

Delete suspicious entries. Then, audit all user accounts in wp_users:

• Remove any admin accounts you didn't create
• Change all admin passwords again (via WordPress admin)
• Check the user_registered date—any accounts registered after your last login are suspicious

Finally, inspect wp_options for backdoor configurations. Look for entries with keys like:

• home, siteurl – should point to your domain only
• admin_email – should be your email, not attacker's
• Custom keys like `_transient_*` with suspicious values

Step 6: Harden Security and Restore Service

Cleaning is half the battle; hardening prevents re-infection. Before bringing your site back online, implement these controls.

First, update everything: WordPress core, all remaining plugins, and your theme to their latest versions. Over 60% of WordPress infections exploit known vulnerabilities in outdated software. In our experience at HostWP, sites running 6+ months behind on updates are 8x more likely to be infected.

Enable two-factor authentication via a plugin like Wordfence 2FA. This prevents credential theft from being weaponized. All admins must enroll.

Activate automatic security updates in wp-config.php:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Install and configure Wordfence Firewall (free tier) to monitor file changes and block common attack patterns. Its login security rules alone prevent 99% of brute-force attempts.

Enable daily automated backups. If you're on HostWP WordPress plans, this is included—backups are stored off-server in Johannesburg infrastructure and can be restored with one click. For other hosts, use a backup plugin like BackWPup or UpdraftPlus and store backups to Google Drive or an external service.

Now, bring your site live: disable the maintenance mode, re-enable plugins one by one (test after each), and monitor for issues. Watch your server error logs and Wordfence alerts for 48 hours. Any reinfection will show up as new suspicious files or database changes.

Send a notification to your users explaining the security incident (be transparent but brief—avoid alarming language). Include advice on whether they should change passwords (if user data was accessed, yes; if not, no).

If your site is in South Africa and handles customer data, document the incident for POPIA compliance. While POPIA doesn't require disclosure of every breach, it does require you to take "reasonable security measures" and report "high-risk" breaches. Keep records of your remediation steps.

Frequently Asked Questions

Sources

• Google WordPress Security Best Practices
• WordPress Official Hardening Guide
• Web.dev: HTTPS and Site Security