Login CAPTCHA Blocks WooCommerce, MemberPress, and Theme Login Forms

Is This Your Issue?

ERROR: Please complete the security challenge

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 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.

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

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:

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+.

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 with the diagnostic info below. Priority email support is included with your GuardPress Pro license — typical response time is within 24 hours.