🔐 WordPress security: why login protection alone is not enough

You set a strong password, changed the login URL, added two-factor authentication, and you think the site is secure? Unfortunately, no. Protecting the WordPress admin login solves only a small part of the problem.

According to the Patchstack 2026 report, the WordPress ecosystem saw 11,334 new vulnerabilities in 2025 alone, 42% more than the year before. 91% of them were in plugins, and nearly half had no fix by the time of public disclosure. Most attacks have nothing to do with the login at all: attackers hunt for holes in theme and plugin code using automated scanners.

Below is a practical breakdown of which measures actually protect a site and which only create an illusion of security.

💡 Quick overview:

• Secure the admin login: strong password, two-factor authentication, and changing the default wp-login.php URL.
• Update the core, themes, and plugins immediately after new versions are released.
• Set up a web application firewall: a cloud WAF plus a WordPress-level plugin.
• Build layered defense from five layers: updates, firewall, access rights, backups, monitoring.

What login protection gives you, and what it misses

Changing wp-login.php to a custom URL, blocking the admin user, strong passwords, and two-factor authentication are all correct measures. They protect against credential guessing and make brute force pointless.

But here are the numbers that change the picture. According to WordPress security research statistics, only a small share of hacks happen through compromised accounts. The main vector is code vulnerabilities: 91% of all found holes live in plugins, 9% in themes, and only a handful affect the WordPress core itself.

In other words: a site with a perfectly secured login but an outdated contact form plugin is easy prey. An automated scanner finds the vulnerability in seconds and exploits it without ever going near the login page.

How WordPress sites are actually attacked

A typical attack does not look like a hooded hacker at a keyboard. It is a bot. Thousands of bots continuously scan the internet looking for sites with known vulnerabilities. They find a plugin with a hole, upload malicious code, install a backdoor, and move on.

Penetration channels that login protection does not close:

• A vulnerability in a plugin or theme allows arbitrary code execution on the server
• An unclosed xmlrpc.php enables brute force via XML-RPC, bypassing wp-login.php
• User data leaking through the REST API, a list of logins for subsequent guessing
• A file with malicious content uploaded through a form without type checking
• Access to wp-config.php or .htaccess through incorrect server permissions

From the Patchstack report for 2026: 17% of new vulnerabilities have high priority, meaning holes that are highly likely to be used in mass automated attacks. Moreover, premium components (paid themes and plugins) contained three times more Known Exploited Vulnerabilities than free ones. Paid does not mean secure.

Five layers of real WordPress protection

Site security is not one plugin or one setting. It is a layer cake where each level closes its own class of threats.

Layer 1: updates, the most underestimated and most important

Updating the core, themes, and plugins immediately after a new version is released is the foundation. But that is not enough: 46% of vulnerabilities in 2025 received no fix from developers before public disclosure. You simply will not know a plugin is vulnerable until a patch comes out.

What to do:

• Enable auto-updates for the core and themes
• Once a week, manually check plugins for updates
• Remove plugins that have not been updated in over a year: they are dead and will become a hole sooner or later
• Replace abandoned plugins with living alternatives

Layer 2: firewall and malicious request blocking

A web application firewall (WAF) filters incoming traffic and blocks requests that look like an attack: SQL injections, cross-site scripting, path traversal. This is a shield that works before the request reaches WordPress code.

Options:

• Cloud WAF at the DNS level (Cloudflare, Sucuri): blocks the attack before it reaches your server
• Firewall plugin at the WordPress level (Wordfence, Solid Security): works inside, but will not save you from a direct server attack
• Firewall at the hosting level: if your host offers one, definitely enable it

The optimal approach is to combine a cloud WAF with a plugin: the first filters out mass noise, the second provides targeted rules for the WordPress ecosystem.

Layer 3: access rights and user accounts

The principle of least privilege: each user gets exactly the rights needed for their work. An author does not need plugin installation. An editor does not need settings access.

Practical steps:

• Never use admin as a login; create a separate administrator with a unique name
• For all users, two-factor authentication (via a plugin or cloud WAF)
• Remove xmlrpc.php if not used (and the vast majority of sites do not need it)
• Limit login attempts: 3-5 attempts → IP block for an hour
• For editors and authors, disable the ability to install and activate plugins/themes

Layer 4: backups, the last line of defense

If all previous layers fail and the site is hacked, a backup is the only way to recover in hours rather than weeks.

Backup strategy requirements:

• Daily automatic backups (files + database)
• Retention for at least the last 30 days
• Backups NOT on the same server as the site (if the server is hacked, you lose the backup too)
• Regular restore testing from backup on a staging site (quarterly)
• Offline copy once a month, in case cloud storage is compromised

Plugins like UpdraftPlus, Solid Backups, or BlogVault cover this task for most sites. For large projects, backup at the hosting or server level.

Layer 5: monitoring and audit

You learn about a hack not when the site stops loading, but when the monitoring system sends a notification.

Minimum set:

• File integrity monitoring: whether the contents of wp-config.php,.htaccess, and theme and plugin files have been changed
• Scheduled malware scanning (Wordfence, Sucuri, Solid Security)
• User action logging: who changed what in the admin panel and when
• Checking site:yoursite.com in Google for spam pages added without your knowledge

What about login protection?

It does not disappear; it remains part of the access rights layer. It simply stops being the only measure. A strong password, a non-standard login URL, and two-factor authentication are a mandatory minimum, but not the only one.

Once you have built the other four layers, login protection logically falls into place: it protects against one specific scenario, credential theft. Not against a hole in a three-year-old gallery plugin.

A visual video on basic WordPress security settings: disabling unused features, configuring permissions, and installing security plugins in 15 minutes.

⁉️🤔 Frequent questions

Is it enough to rely only on a strong password and two-factor authentication?

No. A strong password and two-factor authentication protect only against credential guessing. According to Patchstack data for 2026, 91% of vulnerabilities are in plugins and are exploited without any interaction with the login form. An automated scanner finds a vulnerable plugin, sends a specially crafted request, and gains access to the site; it does not need your password.

Which firewall should I choose for a small WordPress site?

For most sites, the optimal combination is a cloud WAF (Cloudflare free plan) and the Wordfence or Solid Security plugin. Cloudflare blocks attacks at the DNS level; bots are filtered out before the request reaches the server. The plugin adds WordPress-specific rules: brute force protection, file scanning, and change monitoring. Setup takes half an hour.

Do I need to disable xmlrpc.php?

In most cases, yes. xmlrpc.php is only needed if you use the WordPress mobile app, publish through a third-party editor (like MarsEdit), or have connected an external service via XML-RPC. If none of that applies to you, disable it. The file allows up to a hundred login attempts in a single HTTP request, making brute force through it many times faster than through wp-login.php.

How often should I update plugins and themes?

Immediately after an update is released. The gap between vulnerability publication and the appearance of mass attacks has shrunk to a few hours. If a plugin has not been updated in over a year, remove it and find a living replacement. A plugin without updates is not "it works, so it's fine"; it is a potential entry point for an attacker.

What should I do if the site has already been hacked?

First: do not panic and do not blindly delete files. Second: restore the site from the last clean backup. Third: immediately after restoration, change ALL passwords (WordPress, hosting, database, FTP) and update everything to the latest versions. Fourth: install a firewall and set up file integrity monitoring. Fifth: check whether the attacker added hidden administrators to the database. If there is no backup, contact a specialist in cleaning malware from WordPress.

WordPress protection: what actually works

WordPress security is not a product you can buy and forget. It is a process built from five layers: updates, firewall, access rights, backups, and monitoring. Login protection is just a part of one of them.

Start with an audit of the current state: check which plugins have not been updated in over six months, whether xmlrpc.php is enabled, whether you have daily backups, and whether they are stored off-server. Then close the most dangerous holes and build the remaining layers. Half an hour today saves weeks of recovery later.

If the topic of WordPress security is relevant to you, write in the comments which of the five layers is currently your weakest. We will cover it in future materials.