WordPress Hardening in 2026: No Longer Optional

This is not a theoretical problem.

A brand-new WordPress site with zero public content recently saw login attempts using real, valid usernames. Those usernames came from a completely separate, older WordPress site that temporarily lacked security protection. The sites had no content or user relationship.

The attackers connected them through shared server IPs, hosting metadata, REST endpoints, or writing-style fingerprinting. This demonstrates that modern attacks operate across WordPress installs, not site-by-site. Failing to harden even "boring" sites is an open invitation.

What This Attack Looks Like in Practice

Here is what happened:

• Site A (older site) temporarily lost Wordfence protection
• Attackers enumerated valid usernames through REST API or author archives
• Site B (brand-new site) was discovered through shared hosting infrastructure or metadata
• Attackers launched login attempts on Site B using usernames harvested from Site A
• No relationship existed between the sites beyond hosting environment

This is not targeted hacking. This is automated, cheap, and scalable. Bots scan constantly. AI makes enumeration and pattern matching efficient. Credential reuse attacks are profitable because many users reuse passwords.

If you assume your site is too small or too new to be a target, you are wrong.

Critical Countermeasures You Should Implement Today

These are not optional suggestions. These are baseline protections every WordPress site should have configured before going live.

Block xmlrpc.php

The xmlrpc.php file enables remote publishing and pingbacks. It is also a common attack vector for brute force login attempts and DDoS amplification.

Unless you specifically need XML-RPC for Jetpack, mobile apps, or external publishing tools, block it entirely at the server level.

Block REST User Enumeration and ?author= Scans

WordPress exposes usernames through the REST API endpoint /wp-json/wp/v2/users and through author archive URLs like /?author=1.

Attackers scrape these endpoints to build lists of valid usernames. Once they have a username, they only need to guess the password.

Block these endpoints unless you run a headless WordPress setup or intentionally expose user data.

Cloudflare Country-Level Blocking (With Caveats)

Most WordPress login attacks originate from specific geographic regions. If your business only operates in the United States, blocking login access from countries that generate the most automated attacks can reduce noise significantly.

Use this carefully. If you travel, work remotely, or have international clients who need admin access, this can lock out legitimate users. Cloudflare allows you to block by country at the firewall level without touching your site code.

Wordfence (or Equivalent) With Login Hardening Enabled

A security plugin is not a replacement for hardening, but it adds essential layers:

• Brute force protection with rate limiting
• Real-time IP blocking for known attackers
• Login attempt monitoring and alerts
• Malware scanning and integrity checks

Wordfence is a good option, but other reputable alternatives exist. Choose one and configure it properly. Do not just install it and assume you are protected.

Mandatory 2FA for Admins

Two-factor authentication should be required for all administrator accounts. If an attacker guesses or reuses a password, 2FA stops them at the door.

Use a plugin that enforces 2FA for admin roles and supports authenticator apps, not SMS-based codes.

When You Should Not Use These Rules

These hardening rules are not appropriate for every WordPress configuration. Do not blindly apply them without understanding your site's requirements.

Jetpack, Mobile Apps, or External XML-RPC Dependencies

If you use Jetpack, the WordPress mobile app, or any service that publishes to your site remotely, blocking xmlrpc.php will break functionality. You can selectively allow XML-RPC for specific IP ranges or use Jetpack's XML-RPC whitelist feature.

Headless WordPress or Public REST API Use

If your WordPress installation serves as a headless CMS or exposes data through the REST API for a front-end application, blocking REST endpoints will break your site. In this case, secure the API through authentication tokens, not by blocking endpoints.

Multi-Author or Community Sites That Intentionally Expose Users

If you run a membership site, multi-author blog, or community platform where user profiles are public by design, blocking author enumeration defeats the purpose. In this case, focus on enforcing strong password policies and mandatory 2FA instead.

Recommended Apache (.htaccess) Hardening Snippet

Here is a copy-pasteable Apache 2.4-compatible snippet that blocks the most common attack vectors. Add this to your .htaccess file in the WordPress root directory.

# Block xmlrpc.php to prevent brute force and pingback attacks
<Files xmlrpc.php>
    Require all denied
</Files>

# Block REST API user enumeration endpoint
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} ^/wp-json/wp/v2/users [NC]
    RewriteRule ^ - [F,L]
</IfModule>

# Block ?author= user enumeration scans
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{QUERY_STRING} ^author=([0-9]*) [NC]
    RewriteRule ^ - [F,L]
</IfModule>

Each block targets a specific enumeration method. Test your site after adding these rules to ensure no legitimate functionality breaks.

This Is Defense-in-Depth, Not Security by Obscurity

Blocking user enumeration does not make your site secure on its own. Attackers can still guess common usernames like "admin" or your domain name. This is why you layer protections:

• Enumeration blocking makes reconnaissance harder
• Login hardening limits brute force attempts
• 2FA stops stolen or reused credentials
• Security monitoring alerts you to active attacks

No single measure is sufficient. Together, these steps raise the cost and effort required to compromise your site. Most automated attacks move on to easier targets.

If you operate a WordPress site in 2026, basic hardening is no longer optional. Configure these protections before your site goes live, not after you see suspicious login attempts.