WordPress cleanup
Removing .htaccess malware from WordPress – what should you look for?
Removing .htaccess malware from WordPress – what should you look for?
Removing .htaccess malware is rarely finished by pasting back the default WordPress rules. A malicious redirect can disappear and return minutes later because a PHP backdoor, scheduled task or compromised plugin rewrites the file. .htaccess is often the payload, not the source.
Common symptoms
- only visitors arriving from Google are redirected;
- mobile users land on gambling or adult sites;
/wp-adminreturns 403;- an image or text file executes as PHP;
- every request is passed to an unknown loader;
- the site intermittently returns 500;
- cleaned rules keep coming back.
If redirects are the primary symptom, review the broader causes in WordPress redirect malware. JavaScript, database injection and compromised third-party scripts can look identical.
Preserve the original
Save the file, calculate its hash and record ownership, permissions and timestamps before editing:
cp .htaccess ../evidence-htaccess.txt
sha256sum .htaccess
stat .htaccess
find public_html -name '.htaccess' -type f -print
Files below uploads, cache or plugin directories may be legitimate access controls, so location alone is not a verdict.
Suspicious rewrite rules
Pay attention to conditions based on user agent, referrer, cookie, country or device:
RewriteCond %{HTTP_REFERER} google [NC]
RewriteCond %{HTTP_USER_AGENT} "android|iphone" [NC]
RewriteRule ^ https://unknown-example.invalid/ [R=302,L]
This is an illustration, not proof that every similar rule is malicious. Legitimate mobile routing can use conditions. An unknown destination, encoded rule, placement before the WordPress block, or targeting search visitors makes it suspicious.
Also inspect AddHandler or SetHandler rules that execute images as PHP, auto_prepend_file, unusual ErrorDocument targets, long rewrite chains and unknown PHP front controllers.
Restore carefully
Saving permalinks can regenerate the standard WordPress block, but on a compromised site that is not cleanup. Build a minimal clean configuration, then add back only verified custom rules. Test every change:
apachectl configtest
curl -I https://example.com/
curl -I -A 'Mozilla/5.0 (iPhone)' -e 'https://www.google.com/' https://example.com/
Shared hosting may not expose apachectl. A syntax error can take the site down immediately, so keep a recoverable copy and working SFTP access.
When the file is rewritten
This is valuable evidence. Correlate the exact modification time with access logs, PHP processes and scheduled events:
rg -n "\.htaccess|file_put_contents|fopen\(|fwrite\(" wp-content
wp cron event list
Plugins can legitimately write rewrite rules. Determine which request or scheduled event did it and what content was written. WebShield's request-to-file-change correlation is stronger here than a one-time scan.
Inspect beyond .htaccess
Check .user.ini, php.ini, virtual-host and hosting-panel settings. In WordPress, inspect wp-config.php, index.php, mu-plugins, the active theme, database URLs and cron events. Nginx does not process .htaccess, so a similar symptom there comes from different configuration or application code.
Use the guide to safely removing infected WordPress files for quarantining the related loader. If redirects return, persistence remains and the site needs a complete professional cleanup.
The repair is complete only when the configuration validates, the site behaves consistently across user agents and referrers, and monitoring shows no rewrite. The backdoor and entry point must also be gone, with credentials and salts rotated. Otherwise only the visible redirect was removed.