Clean a hacked .htaccess

A hacked .htaccess file is one of the first things to check when your WordPress starts acting up: redirects to an unfamiliar site, an admin you can’t reach, pages that load a foreign script. It’s a quiet config file, sitting at the root, and attackers love it because it runs before WordPress even starts. This article shows you what a clean .htaccess looks like, how to spot injected rules, and how to restore a clean file.

What the .htaccess does (and why attackers target it)

The .htaccess is a config file that the Apache server reads on every request. Normally it handles legitimate jobs: rewriting URLs for clean permalinks, forcing HTTPS, password-protecting a folder, managing redirects after a migration.

The catch is that this file runs ahead of everything else. A rule placed in the .htaccess applies before a single line of WordPress executes. So an attacker who slips their instructions in there can:

• Redirect some of your visitors to a gambling or pharmacy site without touching your content.
• Block access to /wp-admin or wp-login.php to keep you from taking back control.
• Force a hidden PHP file to run on every page load, which keeps a backdoor alive.

The file name starts with a dot, so it’s hidden by default in most file explorers and FTP clients. Remember to turn on showing hidden files before you go looking.

What a clean WordPress .htaccess looks like

Here’s the block WordPress generates by default. This is what should be there, and nothing else if you haven’t added rules yourself:

# 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

Keep this simple rule in mind: everything legitimate and generated by WordPress sits between # BEGIN WordPress and # END WordPress. If your host or a caching plugin added rules, they usually live in their own blocks, also clearly marked and commented (for example # BEGIN WP Rocket).

What should catch your eye is anything sitting before or after those identified blocks, especially if it’s unreadable or mentions a domain you don’t recognize.

The suspicious rules to look for

Here are the most common injections. One alone is enough to compromise the site.

A redirect to an unknown domain. A RewriteRule that sends visitors to an external address you never set up:

RewriteRule ^(.*)$ http://domaine-inconnu.xyz/ [R=301,L]

Conditions on the referer or user-agent. This is the signature of cloaking: the redirect only fires if the visitor arrives from Google, or from a mobile device. You, typing the URL directly, never see a thing.

RewriteCond %{HTTP_REFERER} (google|bing|yahoo) [NC]
RewriteCond %{HTTP_USER_AGENT} (android|iphone) [NC]
RewriteRule ^(.*)$ http://site-casino.xyz/ [R,L]

A hijacked ErrorDocument. Instead of showing your 404 page, the server loads a malicious script on every error:

ErrorDocument 404 /wp-content/uploads/erreur.php

An auto_prepend_file pointing to a backdoor. This directive forces PHP to run a given file before every page. If that file is a backdoor, it runs constantly:

php_value auto_prepend_file /home/compte/public_html/wp-content/uploads/x.php

Encoded code. If you run into long base64 strings, RewriteRule lines with unreadable characters, or directives you don’t understand, treat them as suspicious by default. A legitimate .htaccess is short and readable.

How to clean the file

The safest method is also the simplest: replace the contents with the default WordPress block.

1. Back up the current file before touching anything. Rename it htaccess-infected.txt and download it, in case you need to compare later.
2. Replace all the contents with the standard block shown above. If you had legitimate redirects (after a migration, for example), add them back one at a time, checking each one.
3. Save and test that the site responds normally and the permalinks work.

You can also let WordPress regenerate the file itself. In the admin, go to Settings > Permalinks and click Save Changes without changing anything. WordPress then rewrites a clean .htaccess with the default block. This only works if the file is writable by the server, which is the case on most hosting.

My advice: do both. First replace the contents by hand to be sure the injection is gone, then regenerate via permalinks to confirm WordPress rebuilds a clean file.

Don’t forget the subfolder .htaccess files

This is the classic mistake. You clean the root .htaccess, the problem goes away for a day, then it comes back. The reason: there are other .htaccess files elsewhere in the tree.

WordPress allows a .htaccess in every folder, and each one applies to its own directory. Inspect these in particular:

• wp-content/uploads: it should normally contain no .htaccess at all, or only rules placed by a security plugin. A hacked .htaccess here often serves to re-enable PHP execution in the images folder, which turns a simple attachment into an executable backdoor. Watch for a line like AddType application/x-httpd-php .jpg or a block that allows PHP where there shouldn’t be any.
• wp-includes and wp-admin: no redirect rule has any business there.
• Cache folders and any recently created directory you don’t recognize.

To find them all at once, if you have SSH access:

find . -name ".htaccess"

Examine each result. Any .htaccess outside the root that contains redirect rules or directives about PHP execution deserves a close look.

Confirm the redirect is gone

Once the file is clean, don’t just look at your site from your admin: because of cloaking, that proves nothing. Test under the hack’s conditions:

• Search for your site on Google and click the result, instead of typing the URL.
• Run the test in private browsing, to avoid your cache and cookies.
• Try it on mobile, or by simulating a mobile device from your browser’s developer tools.

If the redirect no longer fires in any of these situations, the .htaccess is clean. For the full rundown when the symptom is a redirect, see the case of a redirect to a casino.

FAQ

I cleaned the .htaccess and the redirect came back. Why? Either there’s still an infected .htaccess in a subfolder (often wp-content/uploads), or an active backdoor on the site re-injects the rule automatically. As long as the entry point stays open, cleaning the .htaccess won’t hold. You need to find the backdoor that re-injects the code.

I can’t find my .htaccess file. It’s hidden because its name starts with a dot. Turn on showing hidden files in your FTP client (often an option like “Force showing hidden files”) or in your host’s file manager. If it really doesn’t exist, your server may not be using Apache (the case with Nginx, which handles these rules differently).

Is it risky to delete the .htaccess? No, as long as you replace it with the default WordPress block. Without a .htaccess, your custom permalinks stop working, but the site stays online. Regenerating the file via Settings > Permalinks fixes that in one click.

The .htaccess is rarely the only spot that’s hit. If you find an injection here, assume other files are infected too, and follow the full guide for when WordPress is hacked for an end-to-end cleanup.

---

If you’d rather not spend your evening on this, WP-Detox offers a free scan that shows you exactly what’s injected in your .htaccess files, root and subfolders included. A full cleanup takes about 30 minutes, at €149 all-in, with a backup taken before any work begins. If we can’t fix your site, you get refunded.