WPFIX STACK — home
Cloudflare & SSL

Cloudflare Challenge Loop on Your WordPress Login? Here's the Exact Fix

Stuck in a Cloudflare Managed Challenge loop on wp-login.php or wp-admin? Here's why it happens and the exact settings to fix it without disabling security.

By Published Updated 6 min read

Hand holding a brass padlock, symbolizing security and protection
Photo by Nathan Thomas on Pexels

If you keep getting thrown back to a Cloudflare "Checking your browser" or "Verify you are human" screen every time you try to reach /wp-login.php or /wp-admin/ — and it never actually lets you through, or it lets you through and then asks again a minute later — a Cloudflare challenge is re-triggering on your own login traffic. It usually comes from a security rule that challenges the login URLs (a WAF custom rule, a managed rule, Bot Fight Mode or Under Attack mode), combined with something in your browser or connection that keeps failing the check. The fix is to find which rule issues the challenge and create a narrow exception for your own login traffic.

Symptoms

  • Visiting wp-login.php or wp-admin shows a Cloudflare interstitial page ("Checking if the site connection is secure" or "Verify you are human") instead of the WordPress login form.
  • Completing the challenge briefly lets you in, then the same challenge reappears on the next page load or after submitting the login form.
  • The loop happens consistently for you (the site owner or an editor) even though regular visitors to the rest of the site don't report it.
  • It got worse recently after you turned on Under Attack mode, added a WAF rule or rate limit, or enabled a bot feature.

Likely causes, in order of how often they actually happen

  1. A rule is challenging the login path. A WAF custom rule or rate limit set to Managed Challenge on /wp-login.php or /wp-admin/, or Under Attack mode for the whole zone, challenges every visit to those URLs — including yours. Cloudflare's old Security Level choices (High, Medium, Essentially Off) are gone: Security Level is now fixed at "Always protected" (opens in a new tab), with only an Under Attack mode switch.
  2. A Cloudflare WAF managed rule or rate-limiting rule is scoring wp-login.php traffic as bot-like, because login pages are a common brute-force target and Cloudflare's managed rulesets specifically watch them more closely than normal pages.
  3. Your connection or browser keeps failing the check. Cloudflare's guide to challenge loops (opens in a new tab) names shared VPNs and corporate proxies with a poor IP reputation, outdated browsers, and extensions such as ad blockers or privacy tools.
  4. Bot Fight Mode is on. It challenges traffic it considers automated, and it can't be skipped with WAF custom rules (opens in a new tab) — only an IP Access rule that matches first, or turning it off, stops it for you.

Fix it: lowest-risk steps first

Step 1 — Find out which rule issues the challenge

In the Cloudflare dashboard, open Security → Analytics → Events and filter for requests to /wp-login.php around the time of the loop. Each challenged request shows the service that issued it — a custom rule, a managed rule, rate limiting or Bot Fight Mode — and that tells you which exception to create. If Under Attack mode is on, turn it off unless you're actually under a DDoS attack; Cloudflare warns it can affect normal traffic such as API calls (opens in a new tab).

Step 2 — Create a WAF custom rule that skips the challenge for the login path

This targets only the pages that need it, instead of lowering security sitewide. In the Cloudflare dashboard:

  1. Go to Security rules (Security → WAF → Custom rules in older dashboards) and select Create rule → Custom rules (Cloudflare's steps (opens in a new tab)).
  2. Set the rule to match when URI Path contains /wp-login.php or URI Path contains /wp-admin/.
  3. For the action, choose Skip and tick only what issued the challenge in Step 1 — for example All remaining custom rules (place this rule above your challenging rule), Managed rules, or Super Bot Fight Mode rules (the full list of skip options (opens in a new tab)). Leave Rate limiting rules unticked so brute-force protection keeps working. There's no "skip Managed Challenge" option, and free Bot Fight Mode can't be skipped this way.
  4. Deploy the rule, and turn Under Attack mode back off if you switched it on only for testing.
  5. Test again in a private window: the login page should load without a challenge, while other parts of the site (and other visitors' login attempts) still go through normal security checks.

Fully exempting /wp-admin/ from challenges — even from Step 2 — means anyone who finds your login URL also skips the challenge, which is a meaningful reduction in brute-force protection. If your office, home, or VPN connection uses a static IP (or a small stable range), tighten the rule:

  1. Edit the custom rule from Step 2 and change the condition to an AND: URI Path contains /wp-login.php or /wp-admin/, AND IP Source Address is in your specific IP (or IP list).
  2. If you don't have a static IP, an alternative is to keep the path-based rule from Step 2 but pair it with a stricter rate limit on /wp-login.php (Security → WAF → Rate limiting rules) so brute-force attempts still get blocked even though the challenge itself is skipped.
  3. Save and confirm the login page loads normally from your own connection.

Verify the fix

  1. Load /wp-login.php in a private/incognito window from your own network and confirm no Cloudflare interstitial appears.
  2. Log in normally and confirm you're not asked to re-verify on the next page load inside wp-admin.
  3. Check Security → Events in Cloudflare a day later to confirm login-path requests from your IP are no longer being challenged, while unrelated traffic elsewhere on the site still shows normal security activity.

If you need to roll back

If the custom rule causes unexpected access issues (for example, a real attacker probing the login page no longer gets challenged at all), delete or disable it on the Security rules page. This immediately returns the site to its prior protection level while you reconsider the IP-scoped version in Step 3.

FAQ

Can I just turn the challenge off for the whole site?

You can remove the rule or feature that issues it, but that takes the protection away from every page. The skip rule in Step 2 is the better long-term fix because it only relaxes checking on the login path — and, scoped to your IP as in Step 3, only for you.

Why does this only happen to me and not other visitors?

Because Managed Challenge decisions are based partly on your specific connection's reputation signals (IP history, VPN/proxy use, request patterns), not a fixed rule that treats all visitors the same. Two people visiting the same login page can get different outcomes.

Is it safe to fully whitelist wp-admin from all security checks?

Not recommended. /wp-admin/ and /wp-login.php are among the most commonly attacked WordPress paths, so removing all Cloudflare protection there — rather than just the challenge, as in Step 2 — leaves you relying entirely on WordPress's own login protections (like a security plugin's login limiter). If you go this route, pair it with strong WordPress-level login protection and, ideally, the IP restriction from Step 3.

Stefan Nistor

Founder, WP Fix Stack

Stefan runs WP Fix Stack. Every guide checks its commands, menu paths and limits against the official documentation of WordPress, PHP, the hosting panel, Cloudflare or the plugin involved, and links those sources so you can verify them. Fixes are ordered from the least risky step, each guide ends with a way to confirm the fix and roll it back, and guides are corrected, with a new Updated date, when the documentation or the software changes.

Every guide explains the symptom, likely causes, the safest order of checks and how to confirm the fix. How we check our guides.

On this page