Predax Security – VPN, Proxy, Tor, Bot Blocker & Firewall

1.17.3

• Fix: site search no longer trips the firewall. Searching for ordinary phrases such as “how to drop table in mysql”, “/etc/passwd” or “wp-config.php” returned a 403 on any site with the firewall on. The search box is now exempt from the SQL-injection, path-traversal, file-probe and command-injection rules; it is still checked for cross-site scripting, because search terms are shown back on the page.
• Security: the CF-Connecting-IP header is now trusted only when the request really arrives from Cloudflare. On a site not behind Cloudflare, anyone could send that header to impersonate any address and bypass the block-list, rate limits and login lockouts.
• Fix: automatic rules can no longer ban a private or loopback address. On a site where every visitor appeared to come from 127.0.0.1 (some proxies and local setups), one honeypot hit put that address on the permanent block-list and locked out the whole site, including WP-Cron. A private address you add by hand still works.
• Fix: every local blocking rule now uses the one shared allow-list check. Seven rules inside the blocker (firewall escalation, JavaScript challenge, fake-bot check, temporary blocks, 404 flooding, honeypot) each kept their own copy, which is how allow-listed visitors kept getting refused in earlier releases.
• Changed: the default blocked user-agent list now contains only attack tools (sqlmap, nikto, wpscan and similar). Generic HTTP libraries such as curl, wget, python-requests, Go and Java clients were removed because uptime monitors, Zapier, Make and most webhook senders identify that way. If you had edited the list, your list is left exactly as it was. The generic entries are still offered on the Settings page if you want them.
• New: Monitor mode on every blocking rule. Tor, malicious-IP, datacenter, country and region blocking, the risk threshold, the firewall, the user-agent list and the 404 threshold can each be set to Monitor: the rule records what it would have blocked in the Threat Log and lets the visitor through. Try a rule before enforcing it. Nothing changes until you pick Monitor; the “Monitor” setup preset now uses it for every rule except the firewall.
• New: Threat Log filters. Switch between Blocked, Monitored (would have blocked) and Flagged, search by IP address or prefix (203.0.113.), pick a date range, sort any column and choose the page size. The CSV export now downloads exactly the filtered view.
• Fix: a honeypot hit in “Log only” mode was recorded with the same action as a blocked one, so the log could not tell them apart.
• Fix: the JS Challenge “Suspicious IPs only” mode was saved but never applied, so the challenge was shown to every logged-out visitor. It now challenges only visitors whose verdict carries a VPN, proxy, Tor, datacenter or malicious flag or a risk score of 30 or more. Choose “All visitors” to challenge everyone except verified search crawlers – the right setting against botnets on residential addresses.
• Note: the Help page now explains that logged-in editors and administrators are never blocked by the firewall, so a test from your own logged-in browser will always get through – test from a private window.
• New: the IP ranges for Jetpack and other trusted services are now refreshed daily from Predax, so a change on the vendor side no longer waits for a plugin update. The built-in list remains as the offline fallback and is never removed by a sync.
• Changed: one compact Predax widget on the WordPress Dashboard instead of two. The attack-versus-your-own-rules breakdown moved to the plugin’s own dashboard page as “Attacks vs Your Own Rules”.
• Fix: the “top threats” list on the dashboard was all-time while the counts beside it were for the week, so the numbers did not add up. It is now the last 7 days.
• Note: verified search-engine crawlers (Googlebot, Bingbot and others verified by IP or reverse DNS) are no longer counted against your Predax plan allowance. A visitor merely claiming to be Googlebot is still counted.

1.17.2

• Fix: the firewall treated every request to xmlrpc.php as an attempted file probe, so Jetpack, the WordPress mobile apps and backup services were blocked on any site with the firewall on — no matter how XML-RPC protection was configured, including when it was switched off. Requests for leaked copies (xmlrpc.php.bak and similar) are still blocked.
• Fix: the IP allow-list is now honoured for XML-RPC. Previously “Disable all XML-RPC” and “Block amplification” ignored it, so an allow-listed client was still refused.
• New: Jetpack is recognised automatically from Automattic’s published IP ranges when Jetpack is installed, so it keeps working without adding anything to the allow-list. Recognised services are exempt from category rules (VPN, datacenter, country, risk score) only — they are still blocked by the firewall, the malicious-IP feed and your own blocklist.

1.17.1

• Fixed: the allow-list was ignored by the user-enumeration protection. If “Block user enumeration” was switched on, author pages and the REST users endpoint were refused for logged-out visitors even when their address was on the allow-list. This was separate from the allow-list problems fixed in 1.17.0, which is why it could still bite after updating. The allow-list is meant to be absolute, and now is.
• Fixed: the comment honeypot could also refuse an allow-listed address. No effect on normal visitors, but it was the last place where “never blocked” was not quite true.

1.17.0

• Fixed: adding your own IP address to the allow-list did not always take effect. A saved decision about a visitor was kept for up to an hour, and allow-listing someone failed to clear it, so page views kept being refused even though the allow-list was correct. Allow-listing an address now takes effect immediately, whether you save it in Settings or use the Allow button in the Threat Log.
• Fixed: an allow-list or block-list entry could be ignored when your site is reachable over both IPv4 and IPv6. The same visitor can arrive in two different notations, and only one of them was being matched. Single addresses and ranges now match either notation.
• New: the IP Allow-list setting now shows the address your site currently sees you as, with a button to add it. Copying your address from an external “what is my IP” service can give you the wrong one, which is what made allow-listing yourself unreliable.
• New: a clear warning on your plugin screens when Predax is refusing your API key – most often because the account’s email address has not been verified yet. Previously screening simply stopped and nothing said so, leaving visitors unchecked with no indication anything was wrong.
• Fixed: the text in the Community Threat Network consent box, and in the privacy notices either side of it, was too faint to read during setup. All of it now meets the standard contrast level.
• Improved: the plugin’s name now describes what it does – VPN, proxy, Tor and bot blocking, plus the firewall. No settings or behaviour change.

1.16.0

• New: a Help page, in the Predax Security menu. Plain-English explanation of every setting, what to choose, and what to do when something is blocked that should not be. It is stored in the plugin, so it works even if your site cannot reach the internet.
• New: optional log retention. The Threat Log and Event Log can now be tidied up automatically. This is OFF by default – nothing is deleted until you choose a number of days under Settings -> Notifications. Once set, the plugin tells you exactly how many entries are affected and waits seven days before deleting anything.
• New: a reminder on your plugin screens when an API key is saved but visitor screening is still switched off, so a half-finished setup no longer sits unnoticed.
• Security: the Threat Log CSV export now neutralises spreadsheet formulas. Attacker-supplied text in a log entry could previously be interpreted as a formula when the file was opened in Excel or Sheets.
• Security: the firewall could be skipped by a request whose address merely contained “/wp-admin”. Exemption is now based on being a logged-in user with editing rights, not on the address.
• Fixed: uninstalling Predax Security removed the settings of Predax Fraud Guard for WooCommerce if both were installed. It now leaves the other plugin alone.
• Fixed: Apple Private Relay and Cloudflare WARP are no longer caught by the datacenter rule, so iPhone visitors are not refused.
• Fixed: AJAX requests from visitors who are not logged in were exempt from IP screening.
• Fixed: the failed-login counter could undercount when many attempts arrived at once, letting an attacker exceed the configured limit before the lockout applied.
• Fixed: the automatic block list is now capped at 5,000 addresses. Addresses you added yourself are never removed.
• Fixed: the dashboard and the WP-CLI status command showed the firewall, Tor and VPN settings as off when they were on.
• Improved: the plugin is now fully translatable. The bundled translation template was previously almost empty, so translations had nothing to work from.

1.15.0

• New: disposable-email screening now checks a continuously updated list of thousands of throwaway providers instead of the short built-in list. Enable it under Settings -> Registration. Only the DOMAIN part of the address is checked (for example “gmail.com”) – the address itself, and everything before the @, never leaves your site. The built-in list is still consulted first and still applies if the API is unreachable, so no site loses a block it had before.
• New: registrations from a domain that cannot receive mail, or with a machine-generated mailbox name, are recorded in the Threat Log. Both are flag-only signals and never block anyone on their own.
• Improved: a visitor already blocked by their IP address no longer triggers an email lookup as well – faster registrations and less of your plan allowance spent.
• Fixed: a malformed email domain could previously cause repeated API errors that temporarily paused IP screening. Malformed domains are now rejected on your own server and never sent.
• Note: email-domain lookups count towards your Predax plan allowance. Results are cached for six hours per domain.