How to Deal With A Hacked WordPress Website

Finding out your WordPress website has been hacked isn’t good news. Knowing how to deal with this, and what to do to clean, secure and harden your WordPress can b e tricky if you haven’t had to deal with this before. This guide should help you deal with a hacked WordPress website.

If, at any point, you’re reading this thinking it sounds nightmarish, we do offer a malware cleanup service to our customers so please let us know if you’d like to take advantage of this service.

There’s a lot of different reasons people hack websites.

Often it’s to do with making money (injecting bitcoin miners for example), sometimes it’s to make use of server side resources (such as sending spam), sometimes it’s for SEO purposes (inserting links to other websites) and sometimes it’s just for kudos (defacement).

There’s also other reasons why people hack websites. The only person that knows for sure, is the person who hacked your site. It’s probably not worth getting hung up on this point.

A lot of hacking is carried out by programs hackers have written, rather than the hacker themselves. For example, a hacker isn’t going to keep typing usernames and passwords in to your website’s login page. They’ll instead write a program that guesses usernames and/or passwords in an orderly manner. The program can attempt to login many more times per minute than a human can. This reduces the time taken to correctly guess login details.

What’s outlined above is a brute force attack (repeated guessing of usernames and passwords). Not all attacks or hacking is like this, though. For what follows to make sense, you need to know a bit about how WordPress works.

WordPress is made by WordPress. Often you’ll install a theme. Usually this theme is made by someone else. You’ll probably install a plugin as well, which is made by someone different from WordPress and who made the theme. You might then install another plugin, which is made by someone completely different. I’m sure you get the picture: Your WordPress is made up of code bases developed and maintained by lots of different parties.

These code bases are, in many cases, not perfect.

The code might run, the plugin might do what it’s supposed to do, but does it do so in a secure manner? Not always.

In the past plugins, or themes, and even WordPress core, have bee found to contain vulnerabilities that could be used to exploit a website. Vulnerabilities often remain undiscovered until the whatever-it-is has been used for some time. When a vulnerability is discovered, it’s usually disclosed (publicly). This allows the person who made the thing that contains the vulnerability to make a patch to fix the vulnerability. The patch is then made available to users of the vulnerable software in the form of an update.

This is why it’s important to apply updates (you did apply your updates, right?). If you don’t apply updates it is a bit like saying “I’ll pass on that thing that prevents my site being hacked, I’m good with this exploitable website, thanks”.

What I’ve just described about vulnerabilities and updates isn’t specific to WordPress alone.

That’s worrying isn’t it?

Yes, we could all be using vulnerable software that just hasn’t had the vulnerability discovered yet. OK, that is a bit unlikely, but some vulnerabilities have remained undiscovered for years!

An extreme example of this is the shellshock vulnerability that was present in the Bash from the late 1980s. This wasn’t disclosed and patched until 2014. That’s around 25 years of unpatched vulnerability.

In many cases, hackers will try to automate the detection and exploitation of known vulnerabilities. This works roughly like this:

Scanners query plugin or theme versions and compare them to vulnerability databases to find known exploits.

When a scanner finds a vulnerable plugin or theme, scripts will attempt to exploit the vulnerability automatically and, on success, install backdoors or web shells.

Once access is gained, automated routines then hack the site (install persistent backdoors, create admin users, inject SEO spam, send spam, or add redirects) all with little or no manual intervention.

There are some things we can do to minimise hacking, and we do indeed do these things. We don’t want you to get hacked. Unfortunately, we can’t completely prevent all hacking though. You’ll need to take some action too (applying your updates and using a good security plugin is often enough).

Hosting providers can’t:

• Fix insecure plugins/themes deployed by the site owner. If a plugin has a zero-day exploit, attackers can still get in until it’s patched. Hosts can block some exploit patterns, but they can’t rewrite third-party plugin code.
• Stop credential theft / social engineering. If an admin’s password is compromised (reused, weak, or phished), the attacker can log in even on secure hosting.
• Prevent every zero-day or novel, well-targeted exploit — some vulnerabilities are discovered and weaponised faster than mitigations can be rolled out.
• Manage content decisions (e.g., publishing dangerous file upload features) — the site owner must practice safe development choices.

Prevention is better than cure in the case of WordPress hacking. There are some basic measures you can take to secure your WordPress:

• Apply updates (you can automate this using plugins such as Easy Updates Manager).
• Use a security plugin that mitigates brute force attacks and tray hardens your WordPress installation such as Wordfence or Solid Security.
• Check that you’re not using anything with known vulnerabilities (Solid Security has a vulnerability scanner in the free version).

Most hackers don’t want you to know that you’ve been hacked. Why would you try and address something you don’t know about? You wouldn’t. A lot of hackers try and keep their hacking unnoticed so you don’t try to remove their hacks.

Sadly this means that you could have been hacked for a considerable amount of time, before noticing that you have been hacked.

Hackers will often try and maintain access to your site. They’ll try and do this in a way that will persist even if you clean your site. Adding administrator users to your WordPress, adding back doors, setting up cron jobs to re-implement back doors are all examples of what hackers will try to maintain access.

As mentioned above, you could have been hacked for a considerable amount of time before noticing anything amiss. Due to this, you won’t always know which backup to restore.

If a hacker did exploit a vulnerability to hack your website, you need to consider that this vulnerability is likely to be present in your backups. If you’re in the position where you knew the date of the hack, and you deleted your site, then restored a backup taken before the hack took place, you could be restoring the vulnerability.

If you do restore the vulnerability, this is likely to be exploited in the same way that it was when you got hacked.

It’s also worth considering that restoring a backup may result in the loss of data, such as orders in the context of an e-commerce website.

If you do decide to restore a backup do bear in mind that it’s possible that this won’t remove files added by hackers. Whether this will happen or not depends on the type of backup you’re restoring.

If you’re restoring an “in hosting account” type backup (i.e. a backup that isn’t administered via your site’s back end), these will usually remove files that have been added by hackers.

On the other hand if you’re restoring a backup that’s administered from within your sites back end/wp-admin, this won’t always remove files added by hackers. Whether this will or won’t depends on where the files have been added, and how that particular backup plugin has been written.

Restoring an “in hosting” type backup is more likely to remove hacked files that have been added to your WordPress (provided the backup is clean), where as it’s questionable that in back end/wp-admin backups will remove hacked files.

You can reinstall WordPress from your site’s back end, and you can also use the WP-CLI command line tool to reinstall plugins, themes, and the WordPress core.

This process will usually overwrite the original files, which helps remove any malicious code that has been injected into legitimate files. For example, if a hacker added harmful PHP code to a theme file or a plugin file, reinstalling will replace that file with a clean version from the official WordPress repository.

However, this approach does not remove files that were added entirely by a hacker, such as new PHP files in the uploads directory, rogue scripts in wp-content or the server root, or backdoor files placed outside the normal WordPress directories. These files are not part of WordPress, plugins, or themes, so reinstalling will leave them in place.

Because of this, reinstalling alone is not a full solution after a hack.

Change your passwords. It’s just sensible to do so. Any password that can be used to login to your website or access its files should really be changed.

Check your hosting. If your hosting account has been compromised, you’re not really looking at a WordPress specific problem here. Someone’s gained access to your hosting, rather than exploiting your website. It’s wise to change your hosting password, check for any FTP users and cron jobs that shouldn’t be present. Hackers may set these up to access your site’s files, or automate re-hacking to maintain their access. Delete any that shouldn’t be present.

Secure your endpoints. Scan your computer with antivirus. In fact scan anything used to log into your WordPress with antivirus. If one of your end points is compromised and this is being used to obtain login credentials, even if you completely clean your site, you’ll just get hacked again.

Most of the work you’ll need to carry out will be at file level. You’ll need access to the file manager in your hosting account to be able to do this.

You’ll also need to be able to find out what’s infected. Often in hosting accounts there will be a virus scanner or malware scanner that you can use to do this. Some providers will need to be asked to scan your account, so you’ll need access to their Helpdesk if this is the case.

There are some plugins that provide malware scanning but your WordPress will need to be in a functional state to use these.

Once you’ve got access to the file manager in your hosting you can get started!

This helps prevent ongoing hacking. To do this, you’ll need to know your public facing IP address. If you’re a netnerd.com customer you can find this by browsing to this page:

https://hello.netnerd.com

Let’s say your IP address is 1.2.3.4

To restrict access to just your IP address locate the .htaccess file in public_html (o the hacked site’s document root). You might need to enable hidden or dotfiles to see the .htaccess file. Then edit the .htaccess file and put this at the top (obviously you’ll need to replace 1.2.3.4 with your IP address), leaving everything else in this file as it is:

order deny,allow
deny from all
allow from 1.2.3.4 

If someone outside your network tries to access your website they’ll now see a 403 forbidden error, which is what we want to happen.

Unless processes are persisting (ask your hosting provider to kill your user processes if you’re concerned about this), only you can access your site. This should mean no ongoing hacking.

Before we get started with anything serious, it might be worth taking a backup. When you use WordPress a lot of what’s present in your hosting account isn’t your data, it’s mostly files that make up WordPress core.

content folder. It might be worth putting copies of these in to a new folder in your hosting just in case.

Netnerd.com build in backups to our shared hosting by default, so you don’t really need to worry about the above if you’re hosted with us.

To check which version of WordPress you’re using open:

public_html/wp-includes/version.php

And you can see the version of WordPress in use on the line that starts with $wp_version:

Make a note of the version in your version.php file.

Now go and get the same version of WordPress from here:

https://en-gb.wordpress.org/download/

You’re going to need this in a minute.

There could be hacked stuff anywhere in the file system of your WordPress installation.

Sometimes hackers will add additional files, sometimes they’ll inject malicious code into files that are part of WordPress, sometimes they’ll do things like give a php script a .jpg extension and put it in your uploads folder. Hacks could be anywhere!

What we’re going to do is delete as much of WordPress as we can, without deleting your website specific stuff, then replace what we’ve deleted with the clean copy of WordPress that you downloaded a moment ago. The reason we’re doing this is because I’m lazy. Well, it’s not completely because I’m lazy, it’s also so that you have less to scan and clean. Yes, that. Honest.

In the file system, all your data is really:
public_html/wp-config.php
public_html/.htaccess
public_html/wp-content

And as the hacks could be anywhere… we’re going to DELETE EVERYTHING ELSE!

While I appreciate this might sound a little bit like unhinged guidance, don’t worry, the stuff we’re going to delete is all replaceable. That’s why you downloaded WordPress.

Delete:
wp-includes
wp-admin
All the .php files that start with wp- EXCEPT FOR wp-config.php

Now the replacing part.

Create a new folder in the top level directory of your hosting. Call it clean_wp. Upload the WordPress file you downloaded from https://en-gb.wordpress.org/download/ to the clean-wp folder, then extract it. You should now have a folder called WordPress in the clean_wp folder, like:
clean_wp/wordpress

In the wordpress folder you’ll find:
wp-admin
wp-includes
wp-content
A load of wp-something.php files.

Copy, or move wp-admin from clean_wp/wordpress to public_html.
Copy, or move wp-includes from clean_wp/wordpress to public_html.
Copy, or move all the wp-something.php files from clean_wp/wordpress to public_html.

Congratulations, you’ve just replaced most of WordPress core with known good clean copies.

If you like, you can apply a similar methodology to your plugins. You’ll need to know which versions of plugins you’re using, which you can find by checking the plugins page in your WordPress back end if it’s functional. If your WordPress back end isn’t functional you might be able to find versions by checking:
public_html/wp-content/plugins/plugin-name/readme.txt
public_html/wp-content/plugins/plugin-name/plugin-name.php
public_html/wp-content/plugins/plugin-name/changelog.txt

You can download specific versions of plugins from:
https://en-gb.wordpress.org/plugins/

By visiting the plugin page, clicking on “advanced view”, then selecting a version to download in the “Previous Versions” section toward the bottom of the page.

You’d then delete the plugin from:
public_html/wp-content/plugins/

Then extract upload the clean downloaded version to:
public_html/wp-content/plugins/
Then extract it.

You do have to be a bit careful you don’t get in a mess with this repetitious process (it helps to keep notes), and you don’t have to do this. If you do, it means less to scan and clean.

You now need to know what’s left that needs cleaning up. To find this out, you’ll need to use the virus or malware scanner in your hosting, or ask your hosting provider to scan your account. If your WordPress is functional, using a plugin based malware scanner may also be an option. Once the scan has completed, you’ll have a list of infected files.

It’s possible that none will be listed as being infected. This could be because you’ve removed the hack with the above. Then again, this could be because the hack isn’t in the malware scanner’s database. You can’t do a great deal about the latter other than use multiple scanners or… manually scrutinise files. Yeugh. Let’s hope it doesn’t come to that.

You should now have a list of infected files.

This is where things can get a bit tricky.

In the scan there’s most likely going to be a mixture of infected files that aren’t part of your WordPress (that contain only malicious code), and files that are part of your WordPress that have had malicious coded added to them (so contain a mixture of legitimate and malicious code).

You can delete the files that aren’t part of WordPress. You’ll need to either manually clean the files that have had malicious code added to them, or replace the infected files with clean versions.

But how can you tell what’s part of your WordPress and what isn’t, and how can you tell what’s malicious code and what isn’t?

You’re going to have to look at the contents of the infected files.

At this point, it’s probably worth me mentioning that we offer malware cleanup service just in case you’re feeling not great about this part.

OK, so, cleaning the code…

Usually, hackers don’t want you to be able to tell what their code does. This makes it different from the legitimate code. Hackers often use a technique called obfuscation to hide what their code does.

Here’s some legitimate PHP code (this is OK):

Here’s a base64 encoded image, (this is OK):

Here’s some obfuscated code (this is not OK):

Can you tell the difference? If you can, you’re probably going to be OK with cleaning the code. If you can’t tell the difference, you’re going to need some help here.

It’s also possible that some of the malicious code might not be obfuscated, so you might need to know how to tell what the code does, to know what to remove.

The objective is to remove all the malicious code, without removing any legitimate code.

If you remove legitimate code, your site will probably error, just to forewarn you.

If a file contains only obfuscated code, it can probably be deleted as it’s unlikely this is part of WordPress (due to the lack of legitimate code).

If a file contains both legitimate and malicious code, you’ll need to remove the malicious code leaving the legitimate code intact.

Once you’ve removed all the malicious code it’s time to move on to…

Your website’s database contains all the variable information specific to your website. Usernames, passwords (MD5 encrypted), the URL of the site, even the content of your site’s pages are all held in the site’s database.

There are usually two database specific issues. One is users that shouldn’t be present (we’ll come to that in a moment) and the other is redirection.

WordPress has its own internal redirect mechanism, which is initially based on the siteurl and home values defined in the options table. Hackers can potentially modify these to make your site redirect to somewhere it shouldn’t.

If your website is redirecting in a way that it shouldn’t checking and correcting the siteurl and and home values defined in the options table (if they’ve been changed) is a good idea.

Redirects can also be handled by JavaScript that’s inserted into site pages. These types of redirects can be implemented in the database or in files.

Initially you’ll need to find the script causing the redirection. You can use website malware scanner such as Sucuri’s Website Malware Scanner to check for JavaScript based redirections. If you still have the .htaccess restriction in place, you’ll need to change this:

order deny,allow
deny from all
allow from 1.2.3.4 

To this:

#order deny,allow
#deny from all
#allow from 1.2.3.4 

In your site’s .htaccess to allow sitecheck.sucuri.net to read your site.

Run your site through sucuri’s site checker, and check the “payloads” to locate the JavaScript code handling the redirection.

You can use PHPMyAdmin to search for the JavaScript that’s causing the redirection in your site’s database.

Remove the malicious JavaScript code by editing the table in which it’s contained to remove the redirection.

It’s possible that the redirecting JavaScript isn’t in the site’s database and is instead defined in a file. The string locator plugin can be used to search your site files for the offending JavaScript code. Again, you’ll need to remove the redirecting JavaScript to get rid of the malicious redirection on your website.

Don’t forget to change this:

#order deny,allow
#deny from all
#allow from 1.2.3.4 

To this:

order deny,allow
deny from all
allow from 1.2.3.4

In your site’s .htaccess to restrict access to just your IP address when you’ve finished using sucuri’s site checker.

Hackers will often add their own user accounts to your WordPress site so they can log in and regain access later. If your site has been compromised, you’ll need to remove any unauthorised users.

It’s usually easier to remove users from the “Users” section of your site’s WordPress dashboard (wp-admin) than it is to do so directly through the database.

The number of users your site has will depend on what kind of site you run.

If you’re the only person who logs in, identifying malicious users is simple. You’d just need to remove any account that isn’t yours.

If you run a blog with multiple authors or an e-commerce site with customer accounts, it can be trickier to determine which accounts are legitimate.

In most cases, hackers will try to create administrator users, giving them unrestricted control over your site. So a good first step is to check for any unfamiliar administrator accounts and delete them immediately.

However, some types of vulnerabilities don’t require hackers to create new admin users at all. These are known as privilege escalation vulnerabilities, where a lower-level account (like a subscriber or customer) can gain administrator access when it shouldn’t. This is why it’s important to review all user roles carefully, not just the obvious admin ones.

If you suspect your WordPress site has been compromised, it’s important to review all existing user accounts. Hackers commonly create hidden administrator users or modify the roles of existing accounts to regain access later.

Log into your site’s WordPress admin area (/wp-admin).

Go to Users → All Users.

Sort by the Role column.

Pay particular attention to any users listed as Administrator.

Review each account carefully.

Remove any that you don’t recognise or that don’t belong to you, your team or your website users.

If unsure, temporarily change the user’s role to “Subscriber” instead of deleting immediately, so you can investigate safely.

Don’t forget to click into user profiles to check for suspicious display names or email addresses (e.g., random Gmail addresses or unfamiliar domains).

If you have SSH or terminal access, you can list all WordPress users quickly using the WP-CLI command:

wp user list

This will show a table like:

+----+---------------+-----------------------+-------------------+-------------+
| ID | user_login    | user_email            | display_name      | roles       |
+----+---------------+-----------------------+-------------------+-------------+
| 1  | admin         | you@example.com       | Admin             | administrator |
| 2  | john          | john@legitdomain.com  | John              | author        |
| 3  | system        | hacked@malicious.com  | System User       | administrator |
+----+---------------+-----------------------+-------------------+-------------+

If you see any users you don’t recognise (particularly ones with the administrator role) you can remove them with:

wp user delete <user_id> --reassign=<safe_user_id>

Replace with the suspicious account’s ID, and with your main admin account (to preserve post authorship if needed).

After deleting or demoting suspicious users:

Reset passwords for all remaining admin accounts.

Enable two-factor authentication (2FA) if possible.

Regenerate the WordPress salts and keys in wp-config.php to invalidate old sessions:

wp config shuffle-salts

By now, if you’ve worked through the above successfully, you should have a clean site, with no redirects, and no malicious users.

It’s now time to secure and harden your WordPress to stop it getting hacked again.

Feel free to make a staging copy at this point if you’re not comfortable applying updates to your live site.

You do need to apply pending updates If any are available, though, as often these will contain patches for vulnerabilities in your website’s codebase. Not applying these may simply mean that the vulnerability that was used to exploit your site is used again in the same way, to hack your site all over again.

It’s possible that you could be using a plugin or theme that contains a known vulnerability that the respective developer hasn’t yet patched. If there’s no patch/update available for a vulnerable plugin or theme, continuing to use this plugin or theme could result in further hacking.

You’ll need to check to see if you are using a vulnerable component that has no patch available.

The free version of the Solid Security plugin has a built in vulnerability scanner.

If you find that you are using a vulnerable plugin or theme and that there’s no patch available all you can really do is remove this from your site to prevent further hacking.

Depending on what you need to remove, this can affect the appearance of your site, so this aspect can be quite a large one.

If you find that you have to remove a plugin, in a lot of cases, there will be an equivalent plugin that provides the same functionality but that isn’t vulnerable. Switching one for the other can be fairly straight forward.

If you find that your theme is vulnerable, switching to a different theme will result in the loss of theme customisation, so you may have to put some time and effort in to reimplementing these customisations.

If you find that the page builder you’re using is vulnerable, moving away from this can be a lot of work. You might find that you have to manually rework you site’s pages if you change page builder, which can be a lot of work depending on the size of your website.

Wordfence is a very commonly used security plugin (although do be aware that the free version’s malware scanner definitions have a 30 day delay to update) and you’ll have seen Solid Security mentioned a few times above. There are a lot of security plugins.

A good security plugin should, at minimum, provide:

• Brute Force Protection – limits failed login attempts and blocks repeated attacks.
• Malware Scanning (optional if hosting malware scanning is available) – detects malicious code, backdoors, and suspicious file changes.
• Firewall / WAF – blocks attacks before they reach your site.
• File Integrity Monitoring – alerts when core, theme, or plugin files are modified.
• Login Security – strong passwords, 2FA, and optional secure login URL.
• IP Blocking / Blacklist – stops known malicious IPs and bot traffic.
• WordPress hardening – Using rules in .htaccess to prevent the execution of scripts in wp-uploads, plugins and theme directories (whether you can enable these or not depends a bit on how your WordPress is set up and the plugins that are installed). This can also be managed manually by adding hardening rules to .htaccess.

This makes it harder for hackers to obtain usernames. You can do this by adding this to the top of your site’s .htaccess file:

# Protect wp-login.php from username enumeration
<IfModule mod_rewrite.c>
RewriteEngine On

# Block requests with "author" query parameter to prevent username discovery
RewriteCond %{QUERY_STRING} author=\d
RewriteRule ^ /? [L,R=301]

# Optional: block access to wp-login.php from unknown IPs (replace 1.2.3.4 with your IP)
# RewriteCond %{REQUEST_URI} ^/wp-login\.php
# RewriteCond %{REMOTE_ADDR} !^1\.2\.3\.4$
# RewriteRule ^.*$ - [R=403,L]
</IfModule>

Remove the restriction in your site’s .htaccess file (so that your site is seen as online by visitors) by removing these lines:

order deny,allow
deny from all
allow from 1.2.3.4 

Using a security plugin that alerts you to file changes is a good idea. Obviously you’ll see batches of files changing when updates are applied, but this is normal and to be expected. One or two files changing when there’s nothing updating should be looked into.

Monitoring access logs is also advisable. This can take a bit of getting used to if you’re not familiar with this aspect, but the sort of things to look out for are:

• Lots of POST requests to wp-login.php or xmlrpc.php: this is indicative of brute force attacks, where an attacker is repeatedly trying to guess usernames and passwords.
• Many requests to URLs containing author= : hackers often use this to enumerate usernames on your site.
• Frequent requests to unusual or non-existent pages: 404 spikes on URLs like /wp-admin/secret.php or /config.php may indicate probing for vulnerabilities.
• Requests with suspicious query strings: for example, strings containing eval(, base64_decode(, or long random characters might indicate an attempt to exploit PHP code.
• High request rates from a single IP: especially if the same IP repeatedly hits login or admin pages; this may indicate a bot or automated attack.
• Requests at unusual times: a large number of admin or login requests outside of normal hours can be a warning sign.
• Multiple failed login attempts logged in a short period: even if spread across different IPs, this can indicate credential stuffing attacks.
• Requests to backup, config, or hidden files: e.g., /wp-config.php.bak or /backup.zip could indicate attempts to download sensitive files.

Well, it’s only sensible really, isn’t it.

First, change all passwords for WordPress, hosting, FTP, and database accounts. Check your hosting account for unauthorised users, cron jobs, or suspicious files. Scan your computer and endpoints for malware. Then, clean your WordPress files and database, restore from a clean backup if available, and harden your site with updates and a security plugin.

Hackers may attack websites for financial gain (like injecting crypto miners), server resources (sending spam), SEO manipulation (injecting links), or just for notoriety (defacement). Often, automated scripts handle most attacks rather than hackers manually.

Common methods include brute force attacks (guessing usernames and passwords rapidly) and exploiting known vulnerabilities in WordPress core, plugins, or themes. Vulnerabilities can remain undiscovered for years, so keeping software updated is essential.

Hosting providers can reduce risk with firewalls, malware scanning, and secure server configurations, but they cannot patch insecure plugins, stop credential theft, or prevent all zero-day exploits. Site owners must maintain updates, strong passwords, and security plugins.

Restoring a backup may remove some malicious files, but it depends on the type of backup. Hosting-level backups are more likely to remove hacker-added files, while backups managed via wp-admin may leave them behind. Ensure the backup is clean and up to date.

Reinstalling overwrites existing files and can remove injected code from legitimate files. However, it does not remove files added entirely by a hacker, like rogue PHP files in uploads or wp-content, so additional scanning and cleaning are needed.

Review all WordPress users in the dashboard under Users → All Users, focusing on administrator accounts. Delete or demote any suspicious accounts. Advanced users can use WP-CLI (wp user list) to inspect and remove unauthorised users. Change all admin passwords and enable two-factor authentication afterward.

Apply all pending updates for WordPress, themes, and plugins. Use a reputable security plugin for malware scanning, firewall protection, brute force prevention, and file integrity monitoring. Restrict access to your IP if needed, harden .htaccess rules, and monitor logs and file changes regularly.

Add the following to your site’s .htaccess file to block requests containing the author= parameter, preventing attackers from discovering usernames:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} author=\d
RewriteRule ^ /? [L,R=301]
</IfModule>

Check access logs for excessive POST requests to wp-login.php or xmlrpc.php, unusual queries, repeated failed logins, high request rates from single IPs, 404 spikes on uncommon URLs, and requests to backup or hidden files. Use a security plugin to receive alerts for file changes and malware detection.