CreaCaptcha

Shared gate that the per-form predicates _wc_*_active() route through — encapsulates the kill-switch, the class_exists check and the master toggle so each form predicate just needs to add its own sub-toggle check.

IN-2: this codebase only ever protects the classic checkout — the render hook (woocommerce_review_order_before_submit) and the verify hook (woocommerce_after_checkout_validation) both fire exclusively from WC_Checkout::process_checkout(), which the Block Checkout's Store API route never calls. This function exists purely to DETECT that gap for wp creacaptcha doctor and the Settings help text — it deliberately does NOT attempt to inject the widget or hook the Store API route (out of scope per the audit's Phase-2 plan; that would be new functionality belonging to its own module).

IN-3: the classic checkout, when the customer checks "create an account?", posts exactly ONE altcha payload but runs it through TWO of our verify hooks within the same request — creationell_captcha_wc_checkout_verify() first (inside WC_Checkout::validate_checkout()), then creationell_captcha_wc_registration_verify() a few lines later (inside WC_Checkout::process_customer() → wc_create_new_customer()), reading the IDENTICAL $_POST['altcha']. The underlying ALTCHA challenge is single-use (class-engine.php's replay-transient marker), so the second check would always find the payload already marked used and fail — an account-creating order could never succeed. Recording the checkout verdict here lets the registration verify reuse it for the same payload instead of re-running the used-marker check a second time.

Scoped to this file/request only (static, resets every request) — it does not weaken replay protection across requests: a genuinely replayed payload from an EARLIER request still hits the used-marker on its very first check here, because this cache starts empty every time.

woocommerce_after_checkout_validation fires inside WooCommerce's process_checkout() after all other validation has run; adding an error to the passed-through WP_Error aborts the order.

Returns a WP_Error to fail the login; otherwise returns the incoming $validation_error value unchanged (so other filters can keep working).

Review fix (Fix-Runde 1, IN-4 critical): an earlier version of this guard checked the dedicated field's mere PRESENCE (isset( $_POST['woocommerce-register-nonce'] )) as its "genuine form" signal. That was exploitable — WooCommerce itself resolves the nonce VALUE via the same _wpnonce fallback implemented here, so an anonymous attacker could read the nonce value off the real registration form's hidden field and resubmit register=…&email=…&_wpnonce=<value> while OMITTING the woocommerce-register-nonce field. WooCommerce would still accept the nonce via its fallback and create the account, while the old, presence-only guard saw no dedicated field and treated the request as "no form context" — skipping the captcha check entirely. Checking the NONCE VALUE (via wp_verify_nonce()) instead of field presence closes this: the fallback is followed identically on both sides, so there is no field-name an attacker can omit to fool this guard while WooCommerce itself still accepts the request.

IN-4: wc_create_new_customer() fires woocommerce_registration_errors — the filter this module hooks — UNCONDITIONALLY, including for the Woo Blocks Store API's own account-creation path and for direct programmatic calls (wp eval, custom scripts, other plugins). Hard- rejecting those whenever no altcha field happens to be present made wc_create_new_customer() unusable outside an actual captcha-protected form — the customer was simply never created.

Both genuine entry points already verify their OWN nonce, inside WooCommerce core, before ever calling wc_create_new_customer() — so independently re-verifying the SAME nonce value/action here (not consuming anything, wp_verify_nonce() is read-only) is a safe, precise signal, as long as it replicates WC's exact field-name fallback (see creationell_captcha_wc_nonce_verifies() above — a presence-only check was exploitable, see that function's docblock):

• Standalone My-Account registration form: WC_Form_Handler::process_registration() gates on isset( $_POST['register'], $_POST['email'] ) plus a valid woocommerce-register nonce (dedicated field woocommerce-register-nonce, falling back to _wpnonce) before ever calling wc_create_new_customer().
• Classic checkout with "Create an account?": WC_Checkout::process_checkout() verifies the woocommerce-process_checkout nonce (dedicated field woocommerce-process-checkout-nonce, falling back to _wpnonce, read from $_REQUEST) before validate_checkout()/process_customer() run — and by the time this filter fires from inside process_customer(), our OWN checkout verify (creationell_captcha_wc_checkout_verify()) has already run too, see IN-3's cache below.

CLI/cron/XML-RPC calls need no explicit exclusion here: none of them ever populate $_POST/$_REQUEST with a nonce that verifies against either action, so both checks below already resolve to false for them without a dedicated SAPI/constant check — one less thing to keep in sync, and it keeps this guard testable by directly setting $_POST (see tests/eval/).

Deliberately does NOT exclude on wp_doing_ajax(): WooCommerce's classic checkout is itself normally submitted via wc-ajax=checkout (WC_AJAX::checkout(), which defines DOING_AJAX itself before dispatch) — excluding AJAX outright would silently re-open IN-3/IN-4 for the majority of real-world checkouts.