Kitgenix CAPTCHA for Cloudflare Turnstile

Kitgenix CAPTCHA for Cloudflare Turnstile adds Cloudflare Turnstile CAPTCHA and anti-spam protection to WordPress, WooCommerce and a wide range of form, membership, community and ecommerce plugins. Challenges are not treated as a client-side decoration: submitted Turnstile tokens are verified server-side with Cloudflare before a protected action is accepted. The plugin is designed for site owners who want to reduce automated login attempts, fake registrations, comment spam, bot-driven checkout abuse and unwanted form submissions while using Cloudflare's privacy-oriented Turnstile challenge rather than a traditional image CAPTCHA. Configuration, integration controls, diagnostics and local verification metrics are managed inside WordPress. The only service required for CAPTCHA functionality is Cloudflare Turnstile itself; no Kitgenix verification proxy is used. Learn more about Kitgenix WordPress plugins at Kitgenix. Supported WordPress and Plugin Integrations The codebase contains dedicated integrations for:

• WordPress login.
• WordPress registration.
• Lost-password and password-reset flows.
• WordPress comments.
• Custom login forms produced with wp_login_form().
• WooCommerce login, registration, lost password, checkout and related account flows supported by the integration.
• WooCommerce Pay for Order (order-payment links), controlled separately from checkout.
• Easy Digital Downloads.
• Elementor forms, including Elementor Pro Forms and the newer Elementor Atomic Forms.
• Contact Form 7.
• WPForms.
• Gravity Forms.
• Fluent Forms.
• Formidable Forms.
• Forminator.
• Ninja Forms.
• Jetpack Forms.
• JetFormBuilder.
• Kadence Forms.
• MailPoet.
• bbPress.
• BuddyPress.
• wpDiscuz.
• Ultimate Member.
• MemberPress.
• Paid Memberships Pro.

Each integration is loaded conditionally and can use integration-specific display/validation behaviour rather than forcing one generic hook onto every form system. Server-Side Turnstile Verification The browser obtains a Turnstile response token from Cloudflare's official widget. When a protected form is submitted, the plugin sends that token to Cloudflare's official Siteverify endpoint using the WordPress HTTP API. The protected action is allowed only when the verification result satisfies the integration's validation flow. This server-side step is important because simply placing a widget in the browser is not sufficient protection on its own. The plugin tracks the most recent verification response, error codes and latency for diagnostics and can record aggregate verification metrics locally. Setup Verification for Login-Sensitive Forms Login, registration and other account-sensitive protections can be gated behind a setup-verification state. The administrator can verify the configured Site Key and Secret Key before those protections are treated as ready. This reduces the risk of enabling a broken key pair on a login screen and accidentally locking legitimate administrators or customers out of the site. Site and secret keys can be supplied from plugin settings or from supported environment variables/constants, allowing security-conscious deployments to keep the secret outside the normal WordPress options table. Replay Protection Turnstile tokens are intended to be short lived and single use. The plugin includes optional replay protection that hashes accepted tokens and temporarily remembers that hash. A token that is submitted again during the replay window can be rejected rather than being accepted repeatedly. The replay window is filterable for developers. Stored replay information is a hash/temporary value, not the raw challenge token itself. Honeypot and Layered Anti-Spam Controls An optional honeypot can be rendered alongside Turnstile. This adds a second low-friction signal for simple bots that fill fields a normal visitor never sees. The plugin also supports whitelisting logic so trusted requests can bypass the challenge where appropriate. Whitelist decisions can take account of configured rules and developer filters rather than hard-coding one bypass mechanism for every site. Trusted Proxy and Client IP Handling Sites may sit behind Cloudflare, another reverse proxy or a load balancer. The client-IP component can be configured to trust proxy headers only when the request path matches the trusted-proxy configuration. This avoids blindly believing spoofable forwarding headers from arbitrary visitors. Administrators can also choose whether the resolved visitor IP is included in the Siteverify request to Cloudflare. A developer filter is available to change that behaviour when required by a site's privacy or infrastructure policy. Widget Appearance and Placement The plugin supports central defaults plus integration-level overrides for Turnstile appearance. Depending on the supported integration, administrators can control options such as theme, size, appearance and language, and can choose placement behaviour where the integration exposes more than one suitable hook. A manual shortcode is also registered: [kitgenix_turnstile] The shortcode is useful when the site owner needs to render the widget in a supported custom workflow. Rendering a widget alone does not automatically secure arbitrary custom PHP processing; custom form handlers must still validate the submitted token server-side. Diagnostics, Metrics and Site Health The plugin includes diagnostics for configuration and verification health, local counters for passed/failed checks, latency information, recent verification events and integration-level metrics. Site Health integration can surface configuration or connectivity issues to administrators. Challenge performance reporting on the Log tab shows how quickly Cloudflare answers server-side verifications (average, 95th-percentile range, slow responses and slowest response) and which forms are seeing more unsuccessful checks than in the previous period, with daily charts, per-form trends, top Cloudflare error codes and a CSV export for the last 7, 14 or 30 days. It keeps only daily counts, response times and error codes per integration – never tokens, IP addresses or submitted form data – and deletes anything older than 60 days automatically. Developer Mode adds additional troubleshooting detail without changing the fundamental requirement that live submissions be verified correctly when protection is active. Settings Portability Settings can be exported and imported for controlled migration between WordPress installations. The transfer system is designed for plugin configuration rather than for exporting visitor submissions or unrelated site data. Performance and Script Loading The public Cloudflare Turnstile script is loaded only for pages/contexts where the plugin determines that a Turnstile widget may be needed. The loader includes duplicate-script detection so multiple integrations do not intentionally enqueue several copies of the same Turnstile API script. Public assets are kept separate from the admin interface, and admin-only diagnostics/settings code does not need to run as part of every anonymous form request. Privacy and Data Flow Turnstile is an external service provided by Cloudflare, so challenge rendering and server-side verification necessarily communicate with Cloudflare. The plugin itself stores configuration and limited diagnostic/aggregate verification data locally. It does not require a Kitgenix account and does not send form contents to Kitgenix for verification. The exact Cloudflare data flow, WordPress.org Hub request and Google Fonts admin request are documented in the External Services section below. Common Uses

• Protect a WordPress login page from automated credential attacks.
• Reduce spam registrations on WordPress or WooCommerce.
• Add anti-bot verification to WooCommerce checkout and account forms.
• Help stop card-testing through WooCommerce order-payment links.
• Protect Elementor and popular WordPress form plugins with one central Turnstile configuration.
• Add a challenge to membership, forum and community registration/login flows.
• Replace more intrusive CAPTCHA experiences with Cloudflare Turnstile while keeping server-side validation.

1. Upload the plugin through Plugins → Add New → Upload Plugin, or install it from the WordPress.org Plugin Directory.
2. Activate Kitgenix CAPTCHA for Cloudflare Turnstile.
3. Create a Turnstile widget in your Cloudflare account and copy its Site Key and Secret Key.
4. Open the plugin settings from the Kitgenix menu in wp-admin.
5. Enter the Site Key and Secret Key and run the setup verification test.
6. Enable only the integrations and forms you want to protect.
7. Test the protected forms while logged out and, where relevant, through checkout/account flows.

A Cloudflare account and Turnstile key pair are required. Your website does not need to use Cloudflare's CDN or proxy service to use Turnstile.

2.2.0 (30 October 2026)

• New: Added Turnstile support for Elementor Atomic Forms (the Editor V4 e-form element in Elementor Pro 4.x), alongside the existing Elementor Pro Forms integration. The widget is added before the form's submit button, a submission without a solved challenge is blocked before it is sent, and every submission is verified server-side before Elementor stores uploads or runs any after-submit actions (email, webhook, collect submissions). The existing Elementor toggle and its Auto-inject/Shortcode-only, theme, size and language settings apply to both form types.
• New: Added WooCommerce Pay for Order protection. A new "Pay for Order Form" toggle (Integrations → WooCommerce) adds Turnstile to order-payment links, such as the "Customer payment page" link and failed or pending payment retries, independently of the checkout toggles. The token is verified before WooCommerce sends the payment to the gateway, helping stop card-testing through shared payment links. It is off by default and is reported as "WooCommerce pay for order" in the Log tab and Test Mode per Integration.
• New: Added Challenge Performance Reporting to the Log tab. It shows Cloudflare Siteverify response times (average, 95th-percentile range, slow responses over 2 seconds and the slowest response) and per-form unsuccessful-check trends compared with the previous period, with daily charts, top Cloudflare error codes, a 7/14/30-day period switch, a CSV export and a "Reset performance data" button. Only daily counts, response times and error codes per integration are stored – never tokens, IP addresses or submitted form data – and data older than 60 days is pruned automatically and removed on uninstall.
• Security: Fixed a login CAPTCHA bypass. A login request sent to an alternative form of the login URL (for example //wp-login.php, /./wp-login.php or /wp%2Dlogin.php) without the Turnstile fields could skip verification, because the check compared the raw request URL against the login URL. Login protection is now decided by the script WordPress actually runs, so every route to wp-login.php is covered, including when a login-URL renaming plugin is used.
• Security: The User-Agent whitelist now only skips loading the widget on page views (GET/HEAD requests), for example for uptime monitors and crawlers. Because user agents can be spoofed, a whitelisted user agent no longer exempts a form submission from Turnstile verification.
• Security: Fixed a possible CAPTCHA bypass through the IP whitelist when "Trust Cloudflare/Proxy Headers" is enabled behind a proxy that appends to X-Forwarded-For (for example a load balancer, nginx or Varnish). The client IP was taken from the left-most public address in X-Forwarded-For, which the visitor controls, so sending X-Forwarded-For: <whitelisted IP> could skip Turnstile verification. The header is now read right to left, skipping your trusted proxies, and the first address the trusted proxy actually saw is used. If that address is not a valid public IP, the proxy's own address is used instead.
• Fix: Resolved a WordPress 6.7+ "translation loading too early" debug notice logged on every request. A settings gate that runs on every options read was building a translated status message every time, even though it only needed a yes/no check. It no longer builds any translated strings.
• Fix: The shared "kitgenix" icon collection/icon was registered unconditionally on init, so on a site running more than one Kitgenix plugin, every plugin after the first to load triggered an "Icon collection is already registered" notice. It is now only registered if not already present.
• Removed: Removed the Kitgenix Plugin Score integration, as Kitgenix Plugin Score has been discontinued. Its settings card, saved settings, setup-verification entries and analytics labels have been removed. Existing saved Plugin Score settings are ignored and are dropped the next time settings are saved.
• Improved: Raised the minimum PHP version to 8.2 (Requires PHP: 8.2). The activation check now also blocks activation on PHP versions below 8.2.
• Improved: Tested up to WordPress 7.4, and reviewed for compatibility with PHP 8.2 to 8.5. The full codebase passes syntax checks on PHP 8.5 and a PHPCompatibility scan for PHP 8.2–8.5, and uses no dynamic properties or functions deprecated in PHP 8.2–8.5.
• Improved: Declared compatibility with the WooCommerce Cart and Checkout blocks (cart_checkout_blocks), so WooCommerce no longer lists the plugin as possibly incompatible in the Checkout block editor.
• Fix: The CSV $escape argument is now passed explicitly in the admin CSV exports, preventing "the $escape parameter must be provided" deprecation notices on PHP 8.4 and later. The CSV format is unchanged.
• Security: Hardened verification by checking the action and hostname fields Cloudflare's siteverify response echoes back, guarding against a token solved on one form being replayed against a different one. Ships in log-only mode this release – mismatches are logged, not blocked, pending full enforcement in a later release.
• Fix: Siteverify requests now send an idempotency key and retry once on a network-level failure, so a retry after Cloudflare already recorded success is no longer incorrectly blocked as a duplicate.
• Fix: Avoided false "Security check failed" errors on page-cached forms. A stale WP nonce on a cached page is now treated as informational (relying on the Turnstile token instead) for non-authentication forms; login, registration and password-reset forms are unaffected and still require a valid nonce.
• Improved: Reduced database write load during a bot flood by rate-limiting diagnostic logging for failed checks, with a tighter limit for a tripped honeypot. Successful checks are unaffected.
• Improved: The replay-protection record is now only stored when an external object cache (Redis/Memcached) is present, avoiding an extra database row per successful check on sites without one.
• New: Added a "Lazy Render Widgets" setting (Settings → Display, off by default) that defers loading a widget until its form scrolls near the viewport, reducing script cost and layout shift on pages with below-the-fold forms.
• New: Added a "Login Lockout" setting (Settings → Security, off by default) that temporarily blocks further login attempts from an IP address or username after too many failures in a row. It also rate-limits XML-RPC and Application Password logins, which share the same underlying check, and clears automatically on a successful login.
• New: Added an optional "Disable XML-RPC" setting (Settings → Security, off by default) for sites that don't rely on the xmlrpc.php endpoint.
• New: Added a "Block User Enumeration" setting (Settings → Security, off by default) that blocks discovering valid usernames via the REST API's users endpoint or the legacy "?author=<id>" link, for logged-out visitors.
• Dev: Hardened the performance-export and log-retention days request parameters to use absint() instead of a raw integer cast.
• Dev: Corrected WordPress coding-standards (PHPCS) escaping and resource-version annotations in the settings UI and script handler; no behaviour change.
• Dev: Removed the PluginScore verification code from the readme, as Kitgenix Plugin Score has been discontinued.
• Dev: Bumped the version to 2.2.0 across the plugin.
• Documentation: Updated DOCUMENTATION.md to remove the Plugin Score integration, describe the new login and User-Agent whitelist behaviour, and document WooCommerce Pay for Order protection and challenge performance reporting.
• Documentation: The regenerated .pot template also picks up the Easy Digital Downloads block strings added in 2.1.4, which were missing from the previous template.
• Documentation: Regenerated the .pot translation template for 2.2.0.
• Documentation: The readme changelog now lists only the current release. The full release history is in CHANGELOG.md.

Full release history is available in the plugin's CHANGELOG.md file.