8grams

Cloudflare for Website Owners · Guides

How to Stop wp-login Brute Force Attacks with Cloudflare (Free Plan)

Your login page is being guessed at right now, by scripts that never sleep. The fix does not require another plugin: Cloudflare can turn those attempts away before they ever reach your server, and every step below works on the free plan.

Why is my wp-login page getting hammered?

Because bots find every WordPress site, and the login page is at the same address on all of them. WordPress puts its login at wp-login.php and its old remote-access endpoint at xmlrpc.php, so automated scripts scan the internet and try passwords on both, millions of sites at a time. The scale is hard to overstate: Cloudflare blocks around 230 billion cyber threats every day, and in 2025 roughly 1 in 2 requests to web pages came from bots. Small sites are not skipped. They are simply next on the list.

Why does this keep happening even with a security plugin?

A login-protection plugin does its work inside WordPress. That means every guess still reaches your server, loads PHP, and often touches the database before the plugin can turn it away. The attempts are blocked, and your server still pays for each one. An edge service like Cloudflare sits in front of your website, so the same junk traffic can be stopped before your server spends anything on it. The three steps below set that up.

Step 1: Put your website behind Cloudflare

If your site is already on Cloudflare, skip ahead. If it is new to you: create a free Cloudflare account, add your domain, and switch your domain's nameservers to the two Cloudflare gives you. Make sure the DNS records for your website show the orange cloud (proxied), because that is what places Cloudflare in front of your server. From that moment, every request to your site passes through Cloudflare first.

Step 2: Rate limit wp-login.php

This is the single highest-impact rule for brute force. A person typing a password needs a handful of attempts. A password-guessing script needs thousands. A rate limiting rule caps how many times one address can hit your login page, so scripts run into a wall while people never notice it.

In the Cloudflare dashboard: Security → WAF → Rate limiting rules. Create a rule where the URI path equals /wp-login.php, set a low request limit per period (for example 5 requests in 1 minute from the same IP), and choose Block for a cooldown period. The free plan includes one rate limiting rule, and this is the place to spend it.

Step 3: Challenge or block xmlrpc.php

The xmlrpc.php file is an old WordPress feature that attackers abuse to amplify password guessing, packing many attempts into a single request. Most modern sites no longer need it. If yours does not, shut the door with a custom rule. If you are not sure, watch Security Events for a few days first to see whether any legitimate service calls it.

In the dashboard: Security → WAF → Custom rules. Create a rule where the URI path equals /xmlrpc.php and set the action to Block, or Managed Challenge if you want a softer option. Custom rules are included on the free plan.

Step 4: Turn on the free managed protections

How do I know it is working?

Open Security → Events in the dashboard. Within hours you should see blocked and challenged requests to /wp-login.php and /xmlrpc.php, each one an attempt that no longer reached your server. Your WordPress login-alert emails and comment-spam queue quiet down for the same reason: the noise is being turned away one step earlier.

Going further

Two upgrades take this from strong to strict. First, put Cloudflare Zero Trust Access in front of /wp-admin, so only your own logins can even reach the admin area; automated attempts never see the login form at all. Second, make sure attackers cannot skip Cloudflare and hit your server directly, by restricting your origin so it only accepts traffic from Cloudflare. Both are free-plan features with a few more moving parts than the steps above.

Want the whole playbook, not just the login page?

This guide is one slice of the ebook Cloudflare for Website Owners: 22 chapters that walk you from connecting your domain to a full hardening checklist, with real dashboard screenshots at every step and a dedicated case-study chapter on securing WordPress end to end. See the WordPress edition of the pitch or the full overview.

Sources: Cloudflare 2026 Threat Report (~230 billion daily blocked threats); Cloudflare Radar 2025 Year in Review (roughly 1 in 2 web requests from bots). Figures rounded. Cloudflare is a trademark of Cloudflare, Inc.; this guide is by 8grams and is not affiliated with Cloudflare, Inc.

Quick Answers

Does this really work on Cloudflare's free plan?

Yes. Everything in this guide uses the free plan: proxied DNS, one rate limiting rule, custom rules, the free managed WAF ruleset, and Bot Fight Mode. Paid plans add more rules and controls, and none of them are required for these steps.

Will I lock myself out of my own login page?

Use a challenge action instead of a block on wp-login.php and you stay safe: a real browser passes the challenge in a second, while most bots fail it. Rate limiting only triggers after repeated attempts from one address, far more than a person typing a password needs.

Do I still need my WordPress security plugin?

Cloudflare stops attack traffic before it reaches your server, and a plugin can still help with things Cloudflare cannot see, such as malware scanning and update management inside WordPress. Many owners keep one lightweight plugin and let Cloudflare absorb the traffic.

What if something breaks after I block xmlrpc.php?

A few tools still use it, for example the Jetpack plugin and the WordPress mobile app. Check Security Events for legitimate traffic to xmlrpc.php before blocking, and if something stops working, remove the rule or switch it to a challenge. The change takes effect in seconds.