fix: false 'behind a proxy' notice on managed hosts, broken notice button; release 2.10.5

cdn-files/plugin-info.json

@@ -1,17 +1,17 @@
 {
     "name": "WebDecoy Bot Detection",
     "slug": "webdecoy",
-    "version": "2.10.4",
+    "version": "2.10.5",
     "author": "<a href=\"https://webdecoy.com\">WebDecoy</a>",
     "author_profile": "https://webdecoy.com",
     "requires": "6.1",
     "tested": "7.1",
     "requires_php": "7.4",
-    "download_url": "https://cdn.webdecoy.com/wordpress/webdecoy-2.10.4.zip",
+    "download_url": "https://cdn.webdecoy.com/wordpress/webdecoy-2.10.5.zip",
     "sections": {
         "description": "<p>WebDecoy provides enterprise-grade bot detection and fraud protection for WordPress websites. Unlike simple CAPTCHA solutions, WebDecoy uses a layered defense approach that analyzes visitors from multiple angles — including deterministic tripwires that catch scanners with zero false positives.</p><h4>Key Features</h4><ul><li>Deterministic tripwires (hidden honeypot paths) — zero-false-positive bot blocking</li><li>Server-side and client-side bot detection</li><li>Invisible proof-of-work challenge (no external CAPTCHA service)</li><li>Comment, login, and registration spam protection</li><li>WooCommerce carding attack prevention</li><li>60+ good bots automatically allowed</li><li>AI crawler detection and blocking</li><li>Optional WebDecoy Cloud: centralized dashboard, rotation-proof device lockouts, and WAF integrations (from your WebDecoy dashboard, push confirmed attackers to Cloudflare or AWS WAF — blocked before they reach WordPress)</li></ul>",
         "installation": "<ol><li>Upload the plugin files to <code>/wp-content/plugins/webdecoy</code></li><li>Activate the plugin through the Plugins menu</li><li>Tripwires and local protection are active out of the box — no API key required</li><li>Optionally go to WebDecoy &gt; Settings &gt; WebDecoy Cloud to connect for centralized monitoring and enforcement</li></ol>",
-        "changelog": "<h4>2.10.4</h4><ul><li>Security: good bots such as Googlebot are now verified against the visitor's real address. A visitor could previously choose the address that was checked by sending a forged forwarding header, and on sites behind Cloudflare, WooCommerce checkout checked Cloudflare's address instead of the visitor's.</li><li>Added: the WebDecoy Cloud tab shows whether Slack and webhook alerts are on for your plan, and where to configure them.</li><li>Changed: corrected descriptions of what WebDecoy Cloud does.</li></ul><h4>2.10.3</h4><ul><li>Fixed: rule violations are no longer sent twice or lost while WebDecoy is briefly unavailable, and AI referral counts refused while WebDecoy was busy are kept and sent later.</li></ul><h4>2.10.2</h4><ul><li>Fixed: pages no longer wait up to 20 seconds when WebDecoy Cloud is slow or unreachable. Detections are sent after the page is delivered, and cloud calls pause for a minute while WebDecoy is unavailable.</li></ul><h4>2.10.1</h4><ul><li>Fixed: 2.10.0 stopped sites loading with a fatal error, &quot;Class WebDecoy_AI_Referrals not found&quot;.</li></ul><h4>2.10.0</h4><ul><li>Added: when connected to WebDecoy Cloud, the plugin counts visits that AI products such as ChatGPT, Claude, Perplexity and Gemini send to your site, for your AI Traffic page. Only the product name, the landing path and a count are sent; nothing about the visitor.</li></ul><h4>2.9.1</h4><ul><li>Fixed: AI search crawlers and assistants fetching a page for a person are no longer identified as AI training crawlers (Claude-User, Claude-SearchBot, MistralAI-User; PerplexityBot is now a search crawler, as Perplexity documents it).</li><li>Changed: with Block AI crawlers on, PerplexityBot and Claude-SearchBot are let through like other AI search crawlers. Assistants fetching for a person, such as ChatGPT-User and Claude-User, are still refused.</li><li>Added: Perplexity-User, MistralAI-User, Meta-ExternalFetcher and Claude-SearchBot are recognised (186 crawlers).</li></ul><h4>2.9.0</h4><ul><li>Added: per-path crawler rules set in WebDecoy Cloud now apply in WordPress too, by the same rule the edge sensor uses. Cloud rules can only refuse, never allow.</li><li>Changed: crawlers are identified from the shared WebDecoy registry (182, was 54); with Block AI crawlers on, AI agents and assistants are refused along with training crawlers.</li></ul><h4>2.3.1</h4><ul><li>Fixed: Detections forwarded from your site are now identified by the visitor's own request signature. Previously they were identified by your server's outgoing connection, which is the same for every visitor — so every visitor a site reported was grouped into a single &quot;actor&quot; in the dashboard. Only request header names plus Accept-Language and Accept-Encoding are sent; no header values leave your site.</li></ul><h4>2.3.0</h4><ul><li>One-click WebDecoy Cloud connect with automatic key provisioning</li><li>Monthly security report opt-in</li><li>Plan entitlements sync (fails open to free)</li><li>Fixed: Statistics charts growing unbounded with detection data</li></ul><h4>2.1.0</h4><ul><li>JS execution verification to catch non-JS HTTP scrapers</li><li>Challenge token meta tag on page serve; automatic page-serve reporting</li></ul><h4>2.0.0</h4><ul><li>All detection and protection now works locally — no API key required</li><li>Invisible proof-of-work challenge system (SHA-256, no external service)</li><li>Behavioral scoring, statistics page, enhanced detections page</li></ul><h4>1.3.0</h4><ul><li>Bulk IP blocking/unblocking; enhanced good bot detection (60+ bots)</li></ul>",
+        "changelog": "<h4>2.10.5</h4><ul><li>Fixed: the warning that WebDecoy is not blocking because the site is behind an unconfigured proxy no longer appears on hosts that already pass the visitor&#039;s real address to WordPress, such as WordPress.com. On those sites blocking was being withheld for no reason.</li><li>Fixed: the warning's &quot;Configure trusted proxies&quot; button, and the monitor-mode &quot;Review and turn on blocking&quot; button, led to a &quot;not allowed to access this page&quot; error. They now open the settings page.</li></ul><h4>2.10.4</h4><ul><li>Security: good bots such as Googlebot are now verified against the visitor's real address. A visitor could previously choose the address that was checked by sending a forged forwarding header, and on sites behind Cloudflare, WooCommerce checkout checked Cloudflare's address instead of the visitor's.</li><li>Added: the WebDecoy Cloud tab shows whether Slack and webhook alerts are on for your plan, and where to configure them.</li><li>Changed: corrected descriptions of what WebDecoy Cloud does.</li></ul><h4>2.10.3</h4><ul><li>Fixed: rule violations are no longer sent twice or lost while WebDecoy is briefly unavailable, and AI referral counts refused while WebDecoy was busy are kept and sent later.</li></ul><h4>2.10.2</h4><ul><li>Fixed: pages no longer wait up to 20 seconds when WebDecoy Cloud is slow or unreachable. Detections are sent after the page is delivered, and cloud calls pause for a minute while WebDecoy is unavailable.</li></ul><h4>2.10.1</h4><ul><li>Fixed: 2.10.0 stopped sites loading with a fatal error, &quot;Class WebDecoy_AI_Referrals not found&quot;.</li></ul><h4>2.10.0</h4><ul><li>Added: when connected to WebDecoy Cloud, the plugin counts visits that AI products such as ChatGPT, Claude, Perplexity and Gemini send to your site, for your AI Traffic page. Only the product name, the landing path and a count are sent; nothing about the visitor.</li></ul><h4>2.9.1</h4><ul><li>Fixed: AI search crawlers and assistants fetching a page for a person are no longer identified as AI training crawlers (Claude-User, Claude-SearchBot, MistralAI-User; PerplexityBot is now a search crawler, as Perplexity documents it).</li><li>Changed: with Block AI crawlers on, PerplexityBot and Claude-SearchBot are let through like other AI search crawlers. Assistants fetching for a person, such as ChatGPT-User and Claude-User, are still refused.</li><li>Added: Perplexity-User, MistralAI-User, Meta-ExternalFetcher and Claude-SearchBot are recognised (186 crawlers).</li></ul><h4>2.9.0</h4><ul><li>Added: per-path crawler rules set in WebDecoy Cloud now apply in WordPress too, by the same rule the edge sensor uses. Cloud rules can only refuse, never allow.</li><li>Changed: crawlers are identified from the shared WebDecoy registry (182, was 54); with Block AI crawlers on, AI agents and assistants are refused along with training crawlers.</li></ul><h4>2.3.1</h4><ul><li>Fixed: Detections forwarded from your site are now identified by the visitor's own request signature. Previously they were identified by your server's outgoing connection, which is the same for every visitor — so every visitor a site reported was grouped into a single &quot;actor&quot; in the dashboard. Only request header names plus Accept-Language and Accept-Encoding are sent; no header values leave your site.</li></ul><h4>2.3.0</h4><ul><li>One-click WebDecoy Cloud connect with automatic key provisioning</li><li>Monthly security report opt-in</li><li>Plan entitlements sync (fails open to free)</li><li>Fixed: Statistics charts growing unbounded with detection data</li></ul><h4>2.1.0</h4><ul><li>JS execution verification to catch non-JS HTTP scrapers</li><li>Challenge token meta tag on page serve; automatic page-serve reporting</li></ul><h4>2.0.0</h4><ul><li>All detection and protection now works locally — no API key required</li><li>Invisible proof-of-work challenge system (SHA-256, no external service)</li><li>Behavioral scoring, statistics page, enhanced detections page</li></ul><h4>1.3.0</h4><ul><li>Bulk IP blocking/unblocking; enhanced good bot detection (60+ bots)</li></ul>",
         "faq": "<h4>Does WebDecoy slow down my site?</h4><p>No. WebDecoy adds negligible latency; tripwire checks are a fast path lookup and clearance minting is idle-deferred.</p><h4>Will it block search engines?</h4><p>No. WebDecoy automatically allows 60+ known good bots including all major search engines, and tripwires only fire on hidden paths no legitimate crawler follows.</p>"
     },
     "icons": {

changelog.txt

@@ -1,5 +1,9 @@
 *** WebDecoy Bot Detection Changelog ***
 
+= 2.10.5 - 2026-10-04 =
+* Fixed: maybe_flag_proxy() flagged an unconfigured proxy whenever an admin request carried any forwarding header. Hosts that rewrite REMOTE_ADDR to the visitor (WordPress.com, nginx real_ip, mod_remoteip) still forward X-Forwarded-For, so the notice showed on nearly every install and enforcement was suppressed with no cause. It now flags only when REMOTE_ADDR is absent from every forwarded address (WebDecoy_Blocker::unresolved_forwarding_header()); stale flags clear on the next admin page load.
+* Fixed: the state notices linked to admin.php?page=webdecoy-settings, which is not a registered page; the settings slug is webdecoy. The proxy button is also anchored to the trusted-proxies field.
+
 = 2.10.4 - 2026-10-04 =
 * Security: BotDetector::analyze(), given signals without ip_address, resolved the client IP from CF-Connecting-IP or the leftmost X-Forwarded-For with no trusted-proxy check, so a client chose the address its claimed good bot was reverse-DNS verified against. It now keeps a valid supplied ip_address and otherwise uses SignalCollector::getIP(), the trusted-proxy-aware resolver; the second resolver is removed (#85).
 * Fixed: WebDecoy_Detector, used by WooCommerce checkout, built its BotDetector without the configured trusted proxies, so behind Cloudflare it verified good bots against the edge address. It now uses webdecoy_plugin_trusted_proxies().

includes/class-webdecoy-blocker.php

@@ -209,6 +209,89 @@ public static function forwarding_header_seen(): string
         return '';
     }
 
+    /**
+     * Like forwarding_header_seen(), but only for a header the server has NOT
+     * already resolved. Most managed hosts (WordPress.com, nginx real_ip,
+     * Apache mod_remoteip) rewrite REMOTE_ADDR to the visitor and still pass the
+     * forwarding headers along. In that case REMOTE_ADDR appears among the
+     * forwarded addresses, every visitor already has their own address, and there
+     * is nothing to fix. Only when REMOTE_ADDR is absent from every forwarded
+     * value is it the proxy rather than the visitor.
+     *
+     * Same restriction as forwarding_header_seen(): admin-side detection only.
+     */
+    public static function unresolved_forwarding_header(): string
+    {
+        $seen = self::forwarding_header_seen();
+        if ($seen === '') {
+            return '';
+        }
+
+        $remote = isset($_SERVER['REMOTE_ADDR'])
+            ? self::canonical_ip(sanitize_text_field(wp_unslash($_SERVER['REMOTE_ADDR'])))
+            : '';
+        if ($remote === '') {
+            return $seen;
+        }
+
+        foreach (array_keys(self::FORWARDING_HEADERS) as $key) {
+            if (empty($_SERVER[$key])) {
+                continue;
+            }
+            $value = sanitize_text_field(wp_unslash($_SERVER[$key]));
+            foreach (self::forwarded_addresses($value) as $addr) {
+                if ($addr === $remote) {
+                    return '';
+                }
+            }
+        }
+
+        return $seen;
+    }
+
+    /**
+     * Every IP address in a forwarding header value, canonicalised. Handles the
+     * comma-separated X-Forwarded-For form and RFC 7239 `Forwarded: for=...`.
+     *
+     * @return string[]
+     */
+    private static function forwarded_addresses(string $value): array
+    {
+        $out = [];
+        foreach (preg_split('/[,;]/', $value) ?: [] as $part) {
+            $part = trim($part);
+            if (stripos($part, 'for=') === 0) {
+                $part = substr($part, 4);
+            } elseif (strpos($part, '=') !== false) {
+                continue; // by=, proto=, host=
+            }
+            $ip = self::canonical_ip($part);
+            if ($ip !== '') {
+                $out[] = $ip;
+            }
+        }
+        return $out;
+    }
+
+    /**
+     * Normalise an address token (quotes, [v6]:port, v4:port) to inet_ntop form,
+     * or '' when it is not an IP.
+     */
+    private static function canonical_ip(string $token): string
+    {
+        $token = trim($token, " \t\"");
+        if (preg_match('/^\[([^\]]+)\](?::\d+)?$/', $token, $m)) {
+            $token = $m[1];
+        } elseif (preg_match('/^(\d{1,3}(?:\.\d{1,3}){3}):\d+$/', $token, $m)) {
+            $token = $m[1];
+        }
+        if (!filter_var($token, FILTER_VALIDATE_IP)) {
+            return '';
+        }
+        $packed = inet_pton($token);
+        return $packed === false ? '' : (string) inet_ntop($packed);
+    }
+
     /**
      * Record a refused block so it is visible rather than silent, and fire a hook.
      *

readme.txt

@@ -4,7 +4,7 @@ Donate link: https://webdecoy.com
 Tags: bot detection, security, spam protection, woocommerce, ai bots
 Requires at least: 6.1
 Tested up to: 7.1
-Stable tag: 2.10.4
+Stable tag: 2.10.5
 Requires PHP: 7.4
 License: GPLv2 or later
 License URI: https://www.gnu.org/licenses/gpl-2.0.html
@@ -285,6 +285,10 @@ The bundled good-bot list (sdk/src/GoodBotList.php) stores a documentation URL f
 
 == Changelog ==
 
+= 2.10.5 =
+* Fixed: the warning that WebDecoy is not blocking because the site is behind an unconfigured proxy no longer appears on hosts that already pass the visitor's real address to WordPress, such as WordPress.com. On those sites blocking was being withheld for no reason.
+* Fixed: the warning's "Configure trusted proxies" button, and the monitor-mode "Review and turn on blocking" button, led to a "not allowed to access this page" error. They now open the settings page.
+
 = 2.10.4 =
 * Security: good bots such as Googlebot are now verified against the visitor's real address. A visitor could previously choose the address that was checked by sending a forged forwarding header, and on sites behind Cloudflare, WooCommerce checkout checked Cloudflare's address instead of the visitor's.
 * Added: the WebDecoy Cloud tab shows whether Slack and webhook alerts are on for your plan, and where to configure them.
@@ -469,6 +473,9 @@ Safety release. Please update. This version deliberately makes the plugin do les
 
 == Upgrade Notice ==
 
+= 2.10.5 =
+Fixes a false "behind a proxy" warning that switched off blocking on many managed hosts, and the broken button in that warning.
+
 = 2.10.4 =
 Security fix: good bots are verified against the visitor's real address, not one a forged header supplies. Recommended upgrade.
 

tests/ProxyDetectionTest.php

@@ -0,0 +1,53 @@
+<?php
+
+declare(strict_types=1);
+
+/**
+ * The admin-side "behind an unconfigured proxy" detection must not fire on hosts
+ * that already resolve REMOTE_ADDR to the visitor and merely pass the forwarding
+ * headers along (WordPress.com, nginx real_ip, mod_remoteip).
+ *
+ * Run: php tests/run.php
+ */
+
+if (!defined('ABSPATH')) {
+    define('ABSPATH', '/tmp/');
+}
+if (!function_exists('sanitize_text_field')) {
+    function sanitize_text_field($s) // phpcs:ignore
+    {
+        return trim((string) $s);
+    }
+}
+if (!function_exists('wp_unslash')) {
+    function wp_unslash($s) // phpcs:ignore
+    {
+        return $s;
+    }
+}
+require_once dirname(__DIR__) . '/includes/class-webdecoy-blocker.php';
+
+echo "\nProxy detection: unresolved forwarding headers\n";
+
+TestRunner::test('flags only forwarding headers the host has not resolved', function () {
+    $saved = $_SERVER;
+    $cases = [
+        'no headers' => [['REMOTE_ADDR' => '203.0.113.5'], ''],
+        'host resolved XFF' => [['REMOTE_ADDR' => '203.0.113.5', 'HTTP_X_FORWARDED_FOR' => '203.0.113.5'], ''],
+        'host resolved XFF chain' => [['REMOTE_ADDR' => '203.0.113.5', 'HTTP_X_FORWARDED_FOR' => '198.51.100.1, 203.0.113.5'], ''],
+        'host resolved CF' => [['REMOTE_ADDR' => '2001:db8::1', 'HTTP_CF_CONNECTING_IP' => '2001:DB8:0::1'], ''],
+        'host resolved Forwarded' => [['REMOTE_ADDR' => '2001:db8::1', 'HTTP_FORWARDED' => 'for="[2001:db8::1]:4711";proto=https'], ''],
+        'host resolved v4:port' => [['REMOTE_ADDR' => '203.0.113.5', 'HTTP_FORWARDED' => 'for=203.0.113.5:443'], ''],
+        'unresolved XFF' => [['REMOTE_ADDR' => '10.0.0.2', 'HTTP_X_FORWARDED_FOR' => '203.0.113.5'], 'X-Forwarded-For'],
+        'unresolved CF' => [['REMOTE_ADDR' => '172.70.1.1', 'HTTP_CF_CONNECTING_IP' => '203.0.113.5', 'HTTP_X_FORWARDED_FOR' => '203.0.113.5'], 'CF-Connecting-IP'],
+        'garbage header' => [['REMOTE_ADDR' => '10.0.0.2', 'HTTP_X_FORWARDED_FOR' => 'unknown'], 'X-Forwarded-For'],
+    ];
+    try {
+        foreach ($cases as $name => [$server, $expected]) {
+            $_SERVER = $server;
+            TestRunner::assertSame($expected, WebDecoy_Blocker::unresolved_forwarding_header(), $name);
+        }
+    } finally {
+        $_SERVER = $saved;
+    }
+});