WordPress Security; From wp-config to Plugins That Are Themselves Vulnerabilities

Is your WordPress site hacked or do you see strange logins?

You wake up on Friday morning and your site has turned into a gambling page. Or worse, Google is warning visitors that your site is "phishing." This scenario has played out for thousands of WordPress site administrators in Iran. If you've recently seen many failed logins in your server logs, or unknown files have appeared in the uploads folder, it's time to take WordPress security seriously. This article is for someone dealing with this problem right now, not for someone who wants a "general overview."

Attacks on WordPress usually happen through one of three avenues: brute force login, a vulnerability in a plugin or theme, or weak server configuration. All three are preventable. But prevention requires technical knowledge, not installing an "all-in-one" plugin that itself becomes a new vulnerability.

First Line of Defense: Lock Down the wp-config.php File

The wp-config.php file is the beating heart of WordPress. If someone gains access to it, they can see your database password, authentication keys, and security settings. The first step is to block direct web access to this file. In the .htaccess file at your site's root, add these rules:

<Files wp-config.php>
Order Allow,Deny
Deny from all
</Files>

This blocks HTTP access to the file. But if your server runs Nginx, you need to add this line to your server block:

location ~ ^/wp-config\.php$ {
    deny all;
}

After this change, test that yoursite.com/wp-config.php returns a 403 error. If it returns 200, your configuration hasn't been applied correctly.

Step two is changing the authentication keys (Salt Keys). If your site was previously hacked and you only deleted the plugins, these keys may be in the attacker's hands. Get new keys from https://api.wordpress.org/secret-key/1.1/salt/ and replace them in your wp-config.php file. After this, all users will need to log in again. That's a good sign, not a problem.

Restricting Login; Where Most Sites Fail

Brute force attacks on the wp-login.php page are the simplest way in. Tools like wpscan and hydra can try thousands of passwords in a few hours. If your password is admin123 or wordpress, your site will be hacked by tomorrow morning.

First task: remove the admin username. If your site still has a user named admin, create a new user with the administrator role and delete the old one. This is the simplest and most effective step.

Second task: limit the number of login attempts. Plugins like Limit Login Attempts Reloaded do this. But if you want to do this without a plugin, you can use fail2ban at the server level. We've explained how to configure fail2ban for SSH in the SSH security guide; the same rules work for WordPress logins, you just need to enable the Apache or Nginx filter.

Third task, which many site administrators skip: two-factor authentication (2FA) for all users, not just administrators. An author with a weak password can be the gateway into your site. If you're using a plugin like Wordfence or iThemes Security, enable 2FA for all roles, not just admins.

Here's Where They Go Wrong: You Install a Login Limiting Plugin But Don't Clear the Cache

After installing a login limiting plugin, the login page might be cached. Users try a few times, get a "too many attempts" error, and you think the plugin is working. But in reality, the attacker continues from a different IP or through a proxy. Login limiting plugins should enforce limits based on IP as well as browser cookies. If your plugin only checks IP, an attacker can easily bypass it by changing IPs through services like VPN or Tor. Choose a plugin that has a "cookie-based restriction" option.

Removing Version Disclosure; Why Tell Everyone What Version of WordPress You Use?

In your site's HTML code, there's the following meta tag:

<meta name="generator" content="WordPress 6.4.2" />

This tag tells an attacker that you're using version 6.4.2. If this version has a known vulnerability, the attacker knows exactly which exploit to use. Removing this tag is simple. Add this code to your theme's functions.php file (or child theme):

remove_action('wp_head', 'wp_generator');

The WordPress version also appears in CSS and JS files. To remove it, add this code:

function remove_wp_version_from_assets($src) {
    if (strpos($src, 'ver=')) {
        $src = remove_query_arg('ver', $src);
    }
    return $src;
}
add_filter('style_loader_src', 'remove_wp_version_from_assets', 9999);
add_filter('script_loader_src', 'remove_wp_version_from_assets', 9999);

This doesn't guarantee 100% security, but it reduces the attack surface. An attacker can still guess the version through other patterns, but it makes their job harder.

Plugins That Are Themselves Vulnerabilities

The biggest mistake in WordPress security is installing unnecessary plugins. Every plugin is a new attack surface. Statistics show that over 90% of WordPress hacks happen through vulnerable plugins, not the WordPress core.

Remove the following plugins immediately:

• Plugins that haven't been updated in over a year.
• Plugins installed from unofficial repositories (cracked or nulled). These plugins usually contain backdoors.
• Plugins that duplicate each other's functionality. For example, three different caching plugins.

Before installing any plugin, ask this question: "Can I do this with 10 lines of code in functions.php?" If the answer is yes, don't install the plugin. For example, to disable XML-RPC (which is a known attack surface), add this code to .htaccess:

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Or in functions.php:

add_filter('xmlrpc_enabled', '__return_false');

XML-RPC is used for connecting mobile apps and external services. If you don't use these services, disable it. Brute force attacks through XML-RPC can try hundreds of passwords with a single request (amplification attack).

Security Plugins: Which One to Choose?

Between Wordfence, Sucuri, and iThemes Security, I recommend Wordfence. The reason is simple: its web application firewall (WAF) is available for free, and its signature database is up to date. But Wordfence consumes server resources. If your site is on a weak shared server, you might be better off using Cloudflare WAF and installing a lighter plugin.

An important note: a security plugin is not a substitute for proper server configuration. If your server isn't up to date or unnecessary ports are open, no plugin will help. For network-level protection, check out DDoS protection. This service adds a layer of security before traffic even reaches your server.

Take Updates Seriously; But Not Blindly

Updating the WordPress core, plugins, and themes is the most important security task. But blind updates can break your site. Before updating, back up your site. If you're on shared hosting, check your host's backup tool. If you have a dedicated server, use wp-cli to back up the database:

wp db export backup-$(date +%Y%m%d).sql

Then test the update in a staging environment. If you don't have a staging environment, perform the update during low-traffic hours and check the site immediately afterward.

Enable automatic updates for critical plugins. Add this line to wp-config.php:

define('WP_AUTO_UPDATE_CORE', true);
add_filter('auto_update_plugin', '__return_true');

But be careful: if you've customized a plugin (modified its code), automatic updates will wipe out your changes. For these plugins, disable automatic updates.

Monitoring and Incident Response

No security is 100%. What matters is detecting an attack early. Enable audit logs to see who logged in, when, and from which IP. Plugins like WP Activity Log do this. But logs are only useful when they're read. Set up email alerts for important events: new administrator login, core file changes, new plugin installations.

At the server level, check your Apache or Nginx logs. If the volume of POST requests to wp-login.php is unusually high, that's a warning sign. You can check this with the following command:

grep "wp-login.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -20

This command shows the top 20 IPs that made the most requests to the login page. If a particular IP has tried dozens of times per minute, block it in your firewall.

To check your site's overall health and whether it's been blacklisted by Google, use DNS and network lookup tools. This tool shows you whether your DNS records have been tampered with. One common attack is changing DNS records to redirect users to a phishing site.

Practical Summary: The 10-Minute Checklist

If you only have 10 minutes, do these tasks:

1. Delete the admin user.
2. Disable XML-RPC.
3. Remove the WordPress version tag.
4. Change the Salt keys.
5. Delete unnecessary and cracked plugins.
6. Apply pending updates.
7. Take a fresh backup and store it off-server.

These tasks repel 80% of common attacks. The remaining 20% requires deeper server configuration. If you feel your site has already been hacked and you don't know what changes the attacker made, the best course is a full reset: reinstall WordPress from scratch, install plugins one by one from the official repository, and get your theme from a trusted source. Then change all passwords. This takes a few hours, but it's the most reliable approach.

If these tasks seem complex or you don't have enough time, ServerNet's security services can perform these checks for you. But even with expert help, you should know the basics so you can verify whether the job was done correctly.

Frequently Asked Questions

How do I know if my WordPress site has been hacked?

Common signs of hacking include changes to your site's appearance, redirects to other pages, Google warnings about phishing or malware, and unknown files in folders. To check, look in the wp-content/uploads folder for PHP files. This folder should not contain any PHP files. Also check the WordPress dashboard for new users with the administrator role.

Is the Wordfence plugin enough for WordPress security?

Wordfence is a good tool but it's not enough. Security plugins only solve part of the problem. Proper server configuration, regular updates, and removing unnecessary plugins are equally important. If you have Wordfence installed but still use a weak password or have outdated plugins, your site's security is still at risk.

Why should I disable XML-RPC?

XML-RPC is an old protocol used to connect external applications to WordPress. Attackers use it to carry out high-volume brute force attacks because they can try hundreds of passwords with a single request. If you don't use the WordPress mobile app or external services that require XML-RPC, disable it.

What should I do after my site has been hacked?

First, put your site into maintenance mode. Second, back up the database and files (for later analysis). Third, change all passwords: hosting, database, FTP, and all WordPress users. Fourth, delete the plugins and theme and reinstall WordPress. Fifth, install plugins one by one from the official repository and check the site. If you don't know what changes the attacker made, a full reset is the safest option.