Interactive Troubleshooter

Published: Sep 19, 2026

WordPress Site Redirecting to Spam: Malware Cleanup

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

An exhaustive technical diagnostic tree designed to identify, isolate, and remove spam redirect malware from WordPress environments. Covers conditional referrer-based redirects, malicious .htaccess rewrite rules, database script injections, obfuscated PHP backdoors, and core file reinjections.

Full Diagnostic Tree & Step-by-Step Overview

When and under what specific conditions does the spam redirect occur on your WordPress site?

Redirect occurs only for visitors coming from search engines (Google, Bing) or specific mobile user-agents.
Redirect triggers globally for all users immediately upon navigating to any site URL or the admin dashboard.
WordPress Site URL and Home settings in the database changed automatically to a malicious external domain.
Random popup/popunder redirects trigger only when clicking anywhere on front-end page elements.

Where is the conditional logic for the referrer or user-agent check likely injected?

Malicious Apache .htaccess or Nginx virtual host rewrite conditions filtering HTTP_REFERER.
PHP auto_prepend_file configuration or injected header code in index.php / wp-config.php.
Obfuscated JavaScript conditionally executing in active theme functions.php or header.php.
Rogue active plugin or rogue gateway drop-in file enforcing cookie-based session redirects.

Remediating .htaccess / Nginx Referrer & User-Agent Rewrite Injections

Solution:

Root Cause: Malicious Server Rewrite Rules

Malware actors tamper with Apache .htaccess or Nginx configuration blocks to inspect incoming HTTP_REFERER and HTTP_USER_AGENT headers. When the server detects a request originating from search engine results (e.g., Google, Yahoo, Bing) or mobile user agents, it returns an HTTP 301/302 location header pointing to spam or phishing landing pages, while bypassing direct requests to evade administrator detection.

# Diagnostic Verification:

1. Connect to your web server via SSH and inspect your .htaccess file:

bash
cat /var/www/html/.htaccess

2. Look for suspicious RewriteCond %{HTTP_REFERER} or RewriteCond %{HTTP_USER_AGENT} rules matching keywords like q=, google, bing, android, or encoded base64 strings.
3. Test conditional response using curl with a spoofed referrer:

bash
curl -I -A "Mozilla/5.0" -e "[https://www.google.com](https://www.google.com)" [https://yourdomain.com/](https://yourdomain.com/)

# Step-by-Step Fix:

1. Quarantine and Reset .htaccess File:

Backup the existing configuration and reset .htaccess to standard WordPress rules:

bash
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak
cat << 'EOF' > /var/www/html/.htaccess
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
EOF

2. Lock File Permissions:

Restrict permission to prevent web server processes from modifying .htaccess:

bash
chmod 644 /var/www/html/.htaccess
chown www-data:www-data /var/www/html/.htaccess

3. Flush Server Caches:

Restart web server and purge object caches (Nginx/LiteSpeed/Varnish).

# Prevention & Long-Term Monitoring:

Implement file integrity monitoring using tools like Fail2ban or Tripwire to alert on root directory file modifications.

Clearing PHP auto_prepend_file & Cloaked Bootstrapping Malware

Solution:

Root Cause: Server-Level PHP Pre-Execution Hijacking

Attackers utilize the auto_prepend_file directive inside .user.ini, php.ini, or .htaccess to force PHP to load a hidden malicious script before executing any legitimate WordPress core files. These scripts execute server-side checks on $_SERVER['HTTP_REFERER'] and send dynamic redirect headers prior to page rendering.

# Diagnostic Verification:

1. Check active PHP configuration for prepended files:

bash
php -i | grep -i auto_prepend_file

2. Inspect root directory for hidden configuration files:

bash
ls -la /var/www/html/ | grep -E '\.user\.ini|php\.ini'

3. Inspect the top lines of index.php and wp-config.php for unverified include, require, or eval() functions.

# Step-by-Step Fix:

1. Remove auto_prepend_file Directives:

Edit .user.ini or php.ini and remove lines referencing unknown .php or .ico files (e.g., auto_prepend_file = /var/www/html/wp-includes/images/sess_x891.ico).

2. Restore Clean Root Files:

Replace root index.php with the official, default WordPress index.php contents:

php
<?php
define( 'WP_USE_THEMES', true );
require __DIR__ . '/wp-blog-header.php';

3. Purge Malicious Prepend Payloads:

Locate and delete the target file referenced in the auto_prepend_file setting.

# Prevention & Long-Term Monitoring:

Disable auto_prepend_file in global server configuration if not strictly required by your hosting stack.

Removing Obfuscated JavaScript Injections in Theme Files

Solution:

Root Cause: Front-End Script Hook Injections

Malware scripts edit active theme templates (header.php, footer.php, functions.php) to insert obfuscated client-side JavaScript. Using encoded strings (String.fromCharCode, eval(atob(...))), the script evaluates the browser document referrer and executes window.location.href = "https://spam-domain.com" for targeted search traffic.

# Diagnostic Verification:

1. Scan active theme files for base64 or obfuscated execution functions:

bash
grep -rnI -E "eval\(atob|fromCharCode|var _0x" /var/www/html/wp-content/themes/

2. Inspect wp_head and wp_footer hooks inside functions.php for unauthorized wp_enqueue_script or inline <script> tags.

# Step-by-Step Fix:

1. Re-install Clean Theme Files:

Re-download a clean copy of your active theme from a verified source and replace all template files.

2. Purge Injected Hooks in functions.php:

Remove any code blocks appending unverified external scripts inside functions.php.

3. Verify File Hashes with WP-CLI:

Check core integrity using WP-CLI:

bash
wp core verify-checksums

# Prevention & Long-Term Monitoring:

Prevent file editing within the WordPress admin dashboard by adding define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php.

Eradicating Rogue Plugins & Cookie-Based Session Redirect Gateways

Solution:

Root Cause: Rogue Plugin Droppers & Session Tracking

Attackers install fake or backdoored plugins (often mimicking legitimate names like wp-seo-service or cache-optimizer). These plugins check if an administrative cookie (wordpress_logged_in_*) is present. If absent, the plugin sets a tracking cookie on the visitor's browser and issues a 302 redirect, ensuring site administrators logged into the dashboard never experience the redirect.

# Diagnostic Verification:

1. List all installed plugins via WP-CLI and check active status:

bash
wp plugin list --status=active

2. Search plugin directories for conditional cookie checks and redirect triggers:

bash
grep -rnI -E "wp_redirect|header\('Location:" /var/www/html/wp-content/plugins/

# Step-by-Step Fix:

1. Deactivate All Plugins via WP-CLI:

bash
wp plugin deactivate --all

2. Isolate and Remove Rogue Plugin Directory:

Inspect /var/www/html/wp-content/plugins/ for folders without official repository metadata and delete them:

bash
rm -rf /var/www/html/wp-content/plugins/rogue-plugin-folder

3. Re-activate Verified Plugins Individually:

bash
wp plugin activate --all

# Prevention & Long-Term Monitoring:

Only download plugins from trusted sources and maintain automated vulnerability scanning via security monitoring tools.

Which core subsystem or application layer is driving the global site redirect?

Infected WordPress core system files (wp-includes, wp-admin, wp-settings.php).
Obfuscated PHP backdoors executing dynamic redirects across all incoming requests.
Rogue PHP drop-in files or fake static scripts executing inside /wp-content/uploads/.
Server-level Nginx / Apache VirtualHost configuration tampering or rogue module.

Replacing Compromised WordPress Core Files (wp-includes & wp-admin)

Solution:

Root Cause: Core Application Binary Tampering

Malware scripts rewrite official WordPress core files such as wp-includes/option.php, wp-includes/default-filters.php, or wp-settings.php. By modifying functions like site_url() or get_option(), the malware intercepts all URL generation calls globally and forces every HTTP response to redirect to external destinations.

# Diagnostic Verification:

1. Verify WordPress core file integrity using WP-CLI:

bash
wp core verify-checksums

2. Output will detail modified, missing, or added core files (e.g., File doesn't verify: wp-includes/option.php).

# Step-by-Step Fix:

1. Download and Overwrite Fresh Core Files:

Force WP-CLI to re-download core files without touching your database or wp-content directory:

bash
wp core download --skip-content --force

2. Purge Unverified Files in Core Directories:

Identify extra PHP files inside wp-includes or wp-admin and remove them:

bash
find /var/www/html/wp-includes/ /var/www/html/wp-admin/ -type f -name "*.php" ! -name "index.php"

3. Verify File Integrity:

Re-run wp core verify-checksums to confirm zero checksum anomalies. Review standard setup guides on WordPress Developer Resources if needed.

# Prevention & Long-Term Monitoring:

Set core directory permissions to strict read-only for the web server user during normal operation.

Purging Obfuscated Base64 / Eval Web Shells and Backdoors

Solution:

Root Cause: Persistent PHP Web Shell Execution

Attackers leave behind hidden backdoor files (e.g., wp-content/uploads/2024/01/db_sess.php or wp-content/plugins/akismet/class-akismet-admin.php). These files utilize multi-stage obfuscation (gzinflate(base64_decode(...))) to accept remote execution commands and force global redirects across all visitors.

# Diagnostic Verification:

1. Search for common obfuscation functions across the entire site path:

bash
grep -rnI -E "base64_decode|gzinflate|eval\(atob|system\(|exec\(" /var/www/html/wp-content/

2. Identify recently created or modified PHP files in the last 7 days:

bash
find /var/www/html/ -type f -name "*.php" -mtime -7

# Step-by-Step Fix:

1. Isolate and Remove Backdoor Files:

Inspect flagged files and delete any unauthorized standalone .php files.

2. Clear PHP OpCache:

Reset PHP-FPM to purge cached malicious bytecode from memory:

bash
systemctl restart php8.2-fpm

3. Change All Security Keys:

Regenerate secret salts in wp-config.php using official WordPress salts to invalidate all existing authentication cookies.

# Prevention & Long-Term Monitoring:

Disable PHP execution in directories where script processing is unnecessary (such as uploads).

Disabling PHP Script Execution in Uploads Directory

Solution:

Root Cause: Executable Upload Directory Abuse

The wp-content/uploads/ directory is designed exclusively for media storage (images, PDFs, videos). Malware actors exploit vulnerable media upload forms or unauthenticated endpoints to upload executable .php files that hijack HTTP requests and enforce redirects.

# Diagnostic Verification:

1. Search for any .php or executable files inside the uploads directory:

bash
find /var/www/html/wp-content/uploads/ -type f -name "*.php*"

2. Any .php file residing in uploads/ is unauthorized and indicates a security compromise.

# Step-by-Step Fix:

1. Delete All PHP Files in Uploads Directory:

bash
find /var/www/html/wp-content/uploads/ -type f -name "*.php*" -delete

2. Block PHP Execution via .htaccess in Uploads Directory:

Create a .htaccess file inside /var/www/html/wp-content/uploads/:

htaccess
<Files *.php>
    Order Deny,Allow
    Deny from all
</Files>

3. Block PHP Execution in Nginx (if applicable):

Add a location block to your Nginx server config:

nginx
location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
    access_log off;
    log_not_found off;
}

# Prevention & Long-Term Monitoring:

Audit file upload MIME types and enforce server-level execution blocks across static media directories.

Remediating Server VirtualHost & Web Server Configuration Tampering

Solution:

Root Cause: Server VirtualHost File Hijacking

When attackers gain root or escalated system privileges, they modify the core web server configuration files (e.g., /etc/nginx/sites-enabled/ or /etc/apache2/sites-enabled/). They inject server-level return 301 or rewrite ^ rules, causing global redirects before request execution even reaches the WordPress PHP engine.

# Diagnostic Verification:

1. Inspect active Nginx server configuration blocks:

bash
grep -rnI -E "rewrite|return 301|proxy_pass" /etc/nginx/

2. Test configuration file syntax for unauthorized modifications:

bash
nginx -t

# Step-by-Step Fix:

1. Restore Web Server Configuration:

Open affected VirtualHost configuration files and remove unverified redirect/rewrite directives.

2. Reload Web Server Service:

bash
systemctl reload nginx
# or for Apache:
systemctl reload apache2

3. Audit User Accounts and SSH Authorized Keys:

Check /root/.ssh/authorized_keys and /etc/passwd to ensure no unauthorized root access was created.

# Prevention & Long-Term Monitoring:

Enforce strict system access controls and utilize centralized logging to track administrative logins.

Which database table or administrative record contains the injected redirect malware?

Site URL (siteurl) and Home URL (home) fields in the wp_options table altered.
Malicious script tags (<script src=...>) injected into wp_posts content or widget options.
Rogue administrator account created in wp_users to maintain database access.
Malicious WP-Cron scheduled tasks constantly re-injecting database redirect payloads.

Restoring Hijacked siteurl & home DB Records in wp_options

Solution:

Root Cause: Core Option Database Injection

Many automated WordPress exploits execute SQL updates targeting the wp_options table. By changing the siteurl and home option values to a spam domain, every request processed by WordPress automatically generates redirect headers to the malicious external URL.

# Diagnostic Verification:

1. Query siteurl and home values using WP-CLI:

bash
wp option get siteurl
wp option get home

2. Alternatively, run SQL queries in phpMyAdmin or MySQL terminal:

sql
SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');

# Step-by-Step Fix:

1. Update Site URLs via WP-CLI:

bash
wp option update siteurl "[https://yourdomain.com](https://yourdomain.com)"
wp option update home "[https://yourdomain.com](https://yourdomain.com)"

2. Hardcode URLs in wp-config.php (Emergency Override):

Edit wp-config.php and add the following constants to prevent runtime overrides:

php
define( 'WP_HOME', '[https://yourdomain.com](https://yourdomain.com)' );
define( 'WP_SITEURL', '[https://yourdomain.com](https://yourdomain.com)' );

3. Clear Object & Transient Caches:

bash
wp cache flush

# Prevention & Long-Term Monitoring:

Restrict database user privileges so remote or web users cannot modify core table structures without credentials.

Cleaning Injected Script Tags in wp_posts & Widget Options

Solution:

Root Cause: Content & Widget XSS Payload Injection

Attackers inject inline HTML script tags (<script src="https://spam-cdn.net/redirect.js"></script>) directly into the post_content column of the wp_posts table or within serialized widget settings in wp_options. When a user loads a post, page, or sidebar widget, the browser downloads and executes the redirect script.

# Diagnostic Verification:

1. Search the database for script tags referencing external domains using WP-CLI:

bash
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%http%'";

2. Search wp_options for script injections in widgets:

bash
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%http%'";

# Step-by-Step Fix:

1. Run Search and Replace via WP-CLI:

Perform a dry run to locate and replace malicious script strings:

bash
wp search-replace '<script src="[https://spam-cdn.net/redirect.js](https://spam-cdn.net/redirect.js)"></script>' '' --dry-run

Execute the replace operation across all database tables:

bash
wp search-replace '<script src="[https://spam-cdn.net/redirect.js](https://spam-cdn.net/redirect.js)"></script>' ''

2. Flush Database Caches:

bash
wp cache flush

# Prevention & Long-Term Monitoring:

Sanitize all input fields and disable raw HTML/JavaScript execution in post content and user comments.

Auditing and Purging Rogue Admin Accounts & Database Backdoors

Solution:

Root Cause: Unauthorized Administrator Privileges

Malware payloads often create rogue administrator accounts (e.g., wp_admin_support or system_user) in the wp_users and wp_usermeta tables. Even after cleaning file injections, attackers log back into the dashboard using these rogue accounts to re-install redirect plugins.

# Diagnostic Verification:

1. List all administrator accounts via WP-CLI:

bash
wp user list --role=administrator

2. Check for users created recently or without recognized email addresses.

# Step-by-Step Fix:

1. Delete Rogue User Accounts:

bash
wp user delete <USER_ID> --reassign=<VALID_ADMIN_ID>

2. Reset All Valid Administrator Passwords:

bash
wp user update <VALID_ADMIN_ID> --user_pass="NewStrongPassword123!"

3. Terminate Active Sessions:

Invalidate all existing user session tokens across the database.

# Prevention & Long-Term Monitoring:

Implement Multi-Factor Authentication (MFA) for all administrative logins and conduct routine user audits.

Clearing Malicious WP-Cron Scheduled Tasks & Automated Reinfection

Solution:

Root Cause: Cron Task Payload Persistence

Attackers register malicious scheduled events in the WordPress cron system (cron option in wp_options). These scheduled tasks run periodically in the background (e.g., every hour) to fetch remote redirect URLs from Command & Control (C2) servers and re-inject modified .htaccess or database options.

# Diagnostic Verification:

1. List all registered WP-Cron events using WP-CLI:

bash
wp cron event list

2. Inspect hook names for suspicious or obfuscated function references (e.g., wp_update_check_event_custom, check_core_version_health).

# Step-by-Step Fix:

1. Delete Malicious Cron Events:

bash
wp cron event delete <HOOK_NAME>

2. Reset Cron Array in Options Table:

Delete the cron option record to force WordPress to regenerate clean core scheduled events:

bash
wp option delete cron

3. Test System Regeneration:

bash
wp cron event list

# Prevention & Long-Term Monitoring:

Disable default WP-Cron execution on page load (define('DISABLE_WP_CRON', true);) and execute cron via system crontab.

What type of front-end script asset or client-side vector is triggering the popunder redirects?

Infected static asset (.js file) inside a nulled theme or plugin package.
Compromised third-party ad network script or Google Tag Manager container.
Script payload stored in transient database cache (_transient_ / object storage).
Persistent web shell injecting client-side click event listeners into rendered pages.

Remediating Nulled Theme/Plugin Asset Trojan Injections

Solution:

Root Cause: Pirated/Nulled Software Supply Chain Compromise

Nulled (pirated) premium themes and plugins frequently contain pre-installed trojan payloads hidden within static JavaScript assets (e.g., assets/js/theme-custom.js or vendor/jquery.min.js). These assets attach global event listeners (document.addEventListener('click', ...)), causing any user click on the page to trigger a popunder spam tab.

# Diagnostic Verification:

1. Open browser Developer Tools (F12), navigate to the Network tab, and reproduce the click redirect.
2. Identify the initiating .js file in the call stack for the redirect request.

# Step-by-Step Fix:

1. Delete Pirated Theme/Plugin Directory:

bash
rm -rf /var/www/html/wp-content/plugins/nulled-plugin-name/

2. Replace with Official Core Assets:

Download official plugin binaries from verified repositories and re-install.

3. Purge Frontend Minification & CDN Caches:

Clear Cloudflare, Fastly, or local caching plugin minified JS caches.

# Prevention & Long-Term Monitoring:

Never download or install nulled or unverified commercial WordPress software.

Securing Compromised Google Tag Manager & Third-Party Scripts

Solution:

Root Cause: Third-Party Script Account Hijacking

If your website integrates Google Tag Manager (GTM), ad networks, or third-party analytics scripts, attackers who compromise your third-party service account can update GTM tags to inject malicious custom JavaScript snippets directly onto your site without needing backend WordPress file access.

# Diagnostic Verification:

1. Inspect site page source (Ctrl + U) and locate embedded GTM or external script containers.
2. Comment out or temporarily remove the GTM container code block from header.php or your header/footer script plugin to test if redirects stop.

# Step-by-Step Fix:

1. Audit GTM Container & Versions:

Log into your Google Tag Manager workspace, check Versions history, and revert to a known clean version prior to the incident.

2. Secure Third-Party Account Access:

Enforce two-factor authentication (2FA) and rotate passwords on all analytics and tag management accounts.

3. Review Injected Tags:

Audit all active Custom HTML tags inside GTM for unauthorized domain requests.

# Prevention & Long-Term Monitoring:

Audit user access permissions on tag management systems and utilize Content Security Policy (CSP) headers to restrict unauthorized script domains.

Flushing Script Injections in Transient Cache & Object Storage

Solution:

Root Cause: Transient Storage Script Persistence

WordPress transients stored in wp_options (with names starting with _transient_ or _transient_timeout_) cache dynamic content and widget data. Attackers inject script payloads directly into transient records, allowing malicious JavaScript to survive theme cleanups until the cache naturally expires.

# Diagnostic Verification:

1. Search the wp_options table specifically for script tags stored in transients:

bash
wp db query "SELECT option_name FROM wp_options WHERE option_name LIKE '%_transient_%' AND option_value LIKE '%<script%'";

# Step-by-Step Fix:

1. Purge All Transients via WP-CLI:

bash
wp transient delete --all

2. Flush External Object Cache (Redis/Memcached):

bash
wp cache flush
# or service restart:
systemctl restart redis-server

3. Verify Database Cleanliness:

Confirm transient options table records are purged of script strings.

# Prevention & Long-Term Monitoring:

Regularly flush expired transients and enforce database security rules.

Neutralizing Persistent Web Shells Injecting Front-End Click Listeners

Solution:

Root Cause: Dynamic Memory & Output Buffer Hijacking

Advanced PHP web shells hook into the ob_start() output buffering mechanism in PHP. Before the final HTML content is delivered to the user's browser, the web shell inspects the outgoing buffer and dynamically inserts client-side click event listeners without modifying static theme files on disk.

# Diagnostic Verification:

1. Compare the raw theme file contents on disk against the rendered HTML page source fetched via HTTP.
2. Search process list for active persistent PHP background processes:

bash
ps aux | grep php

# Step-by-Step Fix:

1. Restart PHP-FPM Service to Terminate Active Memory Hooks:

bash
systemctl restart php8.2-fpm

2. Perform Comprehensive File Scan for Web Shells:

Scan all web root files for output buffering hooks:

bash
grep -rnI -E "ob_start|ob_get_contents" /var/www/html/wp-content/

3. Remove Identified Shell Files & Restore Fresh Core/Theme Installation:

Remove infected files and redeploy clean code from version control or official repositories.

# Prevention & Long-Term Monitoring:

Implement Web Application Firewalls (WAF) such as ModSecurity or Cloudflare to block incoming command execution and web shell communication attempts.

Related Diagnostic Guides

Shader Compilation Stutter in Unreal Engine Games: Fix

AirPods Pro Crackling Sound: Firmware and Cleaning Repair Guide

Screen Time / Family Link Not Blocking Apps

Fast Charging Not Working: PD vs QC Protocol Check

WhatsApp Backup Stuck at 99%: Google Drive / iCloud Diagnostic

Subscribe to StepDiag

Embed Guide on Your Website