# Login CAPTCHA Blocks WooCommerce, MemberPress, and Theme Login Forms
> 'Please complete the security challenge' with no CAPTCHA visible on WooCommerce, MemberPress, or theme logins: GuardPress pre-1.6.17 bug. Update to fix.
- Canonical:
- HTML version:
---
If customers signing in through your WooCommerce `/my-account/` page, MemberPress login form, BuddyPress, bbPress, a theme login widget, or a page-builder login block see **“Please complete the security challenge”** but no CAPTCHA widget is visible on the page, GuardPress pre-1.6.17 was *verifying* the CAPTCHA on every authentication attempt while only *rendering* it on `wp-login.php`. Update to GuardPress 1.6.17 or later and the issue resolves on its own — no settings changes needed.
### Quick fix — almost always the answer
Update GuardPress to 1.6.17 or later from **WP Admin → Plugins → Update Now**. The 1.6.17 release adds the CAPTCHA render to every common login surface and switches verification to fail-open when no token field exists. If you’re already on 1.6.17+ and still seeing this, jump to the [Still Stuck?](#still-stuck) section.
## Is This Your Issue?
#### Symptom
Users on a login surface that is NOT `wp-login.php` get rejected with the message:
```
ERROR: Please complete the security challenge
```
##### Common places it happens
- WooCommerce **My Account** sign-in (`/my-account/`)
- MemberPress, Restrict Content Pro, Paid Memberships Pro login forms
- BuddyPress and bbPress sidebar / member-area login widgets
- Theme-supplied login forms (Astra, Divi, Avada, etc.)
- Page-builder login blocks (Elementor Pro Login widget, Divi Login Module, Bricks, Oxygen, Beaver Builder)
- Any front-end login that uses WordPress’s `wp_login_form()` shortcode or template tag
##### What you see in the form area
No CAPTCHA widget — no math question, no Cloudflare Turnstile box, no checkbox. The form looks completely normal. Users enter correct credentials and get the “security challenge” error every time. Sign-in through `/wp-login.php` directly works perfectly.
If that matches what you’re seeing, this article is for you. If users see an error like “Too many failed attempts” or “Your IP has been blocked,” that’s a different issue — see [Locked Out Recovery](https://royalplugins.com/blog/wordpress-locked-out-recovery/) instead.
## The Fix — Update to GuardPress 1.6.17 or Later
The 1.6.17 release (shipped April 2026) restructured the CAPTCHA rendering so it appears on every common login surface, not just `wp-login.php`. The update is the entire fix — no settings to change, no config to edit.
#### Open WP Admin → Plugins
Go to **WP Admin → Plugins → Installed Plugins** and find GuardPress in the list.
#### Check the version number
If it says 1.6.17 or higher, you’re already updated — jump to [Verify the Fix](#verify). If it’s 1.6.16 or earlier, continue.
#### Run the update
If an update is offered inline, click **update now**. If WordPress says you’re on the latest version but the version is still below 1.6.17, force a refresh: **WP Admin → Dashboard → Updates → Check Again**. The 1.6.20+ SDK fixed a caching bug that occasionally hid available updates — the Check Again button bypasses that cache.
#### Test a login on the affected surface
Open an incognito window, navigate to the WooCommerce / MemberPress / theme login form, and sign in. You should now see the CAPTCHA widget render in the form, and a correct sign-in should complete normally.
No data loss, no settings reset
The 1.6.17 update is a render-side change only. All your CAPTCHA settings (provider choice, Turnstile keys, math question difficulty), brute-force lockout counters, IP whitelists, and audit logs are preserved exactly as configured.
## What Surfaces Are Now Protected (1.6.17+)
The 1.6.17 release added the CAPTCHA render to the following WordPress / WooCommerce action hooks. Any login form using these hooks (which is essentially every well-behaved theme, page builder, and membership plugin) now displays the CAPTCHA widget correctly:
- `login_form` — the original `wp-login.php` form (already covered pre-1.6.17)
- `register_form` — the registration form on `wp-login.php?action=register`
- `lostpassword_form` — the password-reset form on `wp-login.php?action=lostpassword`
- `login_form_bottom` — **the catch-all hook fired by `wp_login_form()`**, which is what every standards-compliant front-end login form uses (theme login widgets, BuddyPress, bbPress, MemberPress, Restrict Content Pro, Paid Memberships Pro, and most page-builder login blocks)
- `woocommerce_login_form` — WooCommerce `/my-account/` sign-in tab
- `woocommerce_register_form` — WooCommerce `/my-account/` registration tab
- `woocommerce_lostpassword_form` — WooCommerce password-reset
If your login surface uses any of these hooks (the vast majority do), the CAPTCHA widget will render automatically with no theme or plugin code changes required.
## Surfaces That Still Don’t Render a CAPTCHA — and Why That’s OK
Some login surfaces are inherently programmatic and can’t render an interactive challenge. For these, GuardPress 1.6.17+ uses **fail-open verification**: if a sign-in request arrives with no CAPTCHA token field at all (meaning the form physically didn’t include the widget), the CAPTCHA check is skipped and the request proceeds to brute-force lockout instead.
- **WordPress REST API** — basic-auth or app-password sign-ins to `/wp-json/wp/v2/users/me` and similar endpoints
- **Application Passwords** — the credential type WordPress uses for headless / mobile-app auth (introduced in WP 5.6)
- **XML-RPC** — legacy clients like the WordPress mobile apps before they migrated to REST
- **Custom AJAX login handlers** — some membership plugins build their own AJAX submit instead of standard form POST
Brute-force lockout still applies to all surfaces
Fail-open on the CAPTCHA layer does **not** mean these surfaces are unprotected. GuardPress’s brute-force lockout (failed-login tracking + temporary IP block) runs on the `authenticate` filter for *every* sign-in attempt regardless of the surface. An attacker hitting `/wp-json/` with bad credentials still gets their IP blocked after the configured threshold. The CAPTCHA layer is one of several gates, not the only one.
When a sign-in request *does* carry a CAPTCHA token field, verification is strict and fail-closed — a present-but-invalid token is rejected. Only fully-absent token fields trigger the fail-open path.
## Verify the Fix
After updating, run through these checks to confirm the issue is resolved:
#### Hard-refresh the affected login form
Open the WooCommerce `/my-account/` page (or MemberPress login, theme login form, etc.) in an incognito window. The CAPTCHA widget should now be visible inside the form — either a math question (e.g. “What is 3 + 7?”) or the Cloudflare Turnstile checkbox, depending on which provider you have selected.
#### Complete a real sign-in
Solve the CAPTCHA and submit the form with valid credentials. Sign-in should complete normally with no “security challenge” error.
#### Confirm brute-force protection is still active
Submit the form with deliberately wrong credentials a few times. After hitting the threshold configured in the Brute Force Protection row under **GuardPress → Settings → Login Protection**, your IP should be temporarily blocked and you should see the lockout message. Reset your block from **GuardPress → IP Management** when done testing.
#### Check the GuardPress audit log
Open **GuardPress → Audit Log** and filter for recent login events. Successful sign-ins on the affected surface should now appear with `login_success` entries.
## If You Can’t Update Right Now — Temporary Workaround
If you’re in the middle of an active issue and can’t update GuardPress immediately (maintenance window, change-control gate, customer site you don’t have admin access on), the safest stopgap is to temporarily disable Login CAPTCHA:
1. Go to **GuardPress → Settings → Login Protection**
2. Turn off **Login CAPTCHA**
3. Save settings
This removes the CAPTCHA from *all* login surfaces (including `wp-login.php`) until you re-enable it. Brute-force lockout remains active on every surface, so your site is still protected against credential-stuffing attacks — you’ve just temporarily lost one layer of bot defense. Re-enable the CAPTCHA after you update to 1.6.17+.
This reduces protection — treat it as a stopgap
Disabling the CAPTCHA removes a real defense layer. The proper fix is updating GuardPress to 1.6.17 or later. If you can’t update within the day, escalate the update window rather than leaving the CAPTCHA off indefinitely.
## Why Did This Happen?
Pre-1.6.17 the CAPTCHA was wired into WordPress with an asymmetric pair of hooks:
- **Render** via the `login_form` action — which only fires inside `wp-login.php`
- **Verify** via the `authenticate` filter — which fires for *every* authentication attempt regardless of which login surface initiated it
That worked perfectly as long as sign-ins only happened on `wp-login.php`. The moment a WooCommerce store, a membership plugin, or a custom theme login was introduced to the site, sign-ins started arriving at the `authenticate` filter with no CAPTCHA token field — because the form on those surfaces never had a CAPTCHA widget to fill in — and the verification rejected them all.
The 1.6.17 fix had two parts:
1. **Render the CAPTCHA on every standard login surface** — by hooking `register_form`, `lostpassword_form`, `login_form_bottom`, `woocommerce_login_form`, `woocommerce_register_form`, and `woocommerce_lostpassword_form` in addition to the original `login_form`. That covers WooCommerce, MemberPress, RCP, PMP, BuddyPress, bbPress, the `wp_login_form()` shortcode/template tag, and most page-builder login widgets without per-plugin integration.
2. **Switch verification to fail-open semantics when no token field is present** — if a sign-in request arrives with no CAPTCHA field whatsoever (REST API basic auth, Application Passwords, XML-RPC, custom AJAX handlers), the verification is skipped and the request proceeds to brute-force lockout. A present-but-invalid token is still rejected; only fully-absent fields trigger the fail-open path.
The combination means the CAPTCHA layer is now actively useful on every login surface where it can render and harmlessly skipped on surfaces where it can’t — with brute-force lockout running uniformly across all of them.
## Still Stuck? Email Priority Support
If you’ve updated to GuardPress 1.6.17+ and verified the version in WP Admin, and the CAPTCHA still isn’t rendering on the affected login surface, the form is most likely using a custom AJAX submit handler instead of standard WordPress login hooks. A small number of bespoke membership plugins and heavily customised themes fall into this category.
Email **[support@royalplugins.com](mailto:support@royalplugins.com)** with the diagnostic info below. Priority email support is included with your GuardPress Pro license — typical response time is within 24 hours.
#### Information to include in your email
- **GuardPress version** from **WP Admin → Plugins** (must be 1.6.17 or higher)
- **WordPress version** from **WP Admin → Updates**
- **The exact URL of the failing login form** (e.g. `https://example.com/my-account/`)
- **Which plugin or theme** renders that login form (WooCommerce, MemberPress, Astra Pro, Elementor Pro Login widget, etc.) — include version numbers
- **Screenshot of the form itself** — showing whether the CAPTCHA widget is visible or absent
- **Screenshot of the error message** users see when they try to sign in
- **The HTML source of the form** (right-click → View Page Source, then paste the `