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

Changelog

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.

1.14.0

Crawler Policy — decide which crawlers may access your site
* New: independent allow/block switches for search engines (Googlebot, Bingbot, DuckDuckBot, Applebot), AI crawlers (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot) and SEO crawlers (AhrefsBot), in Settings → Protection → Crawler Policy.
* Enforcement uses the IP ranges each operator publishes — verified identity, not the user-agent header — so unlike robots.txt (a request) or user-agent blocking (trivially faked), a blocked crawler is actually turned away. A visitor merely claiming a crawler’s user-agent is neither blocked nor allowed by this policy; your normal rules apply to them in full.
* All three switches default to Allow, so nothing changes on your site until you switch one off. Blocks appear in the Threat Log with their own reasons.

Search-engine safety
* Fix: verified search engine crawlers are no longer served the JavaScript Challenge page. That page returns HTTP 200 with no real content, so a challenged crawler could index « Verifying your browser… » in place of your pages. The exemption requires DNS-verified identity — a faked crawler user-agent still gets the challenge.
* Fix: crawler verification now accepts reverse-DNS names in any capitalisation, and with or without the trailing dot. Previously a legitimate crawler whose DNS answered in mixed case could be treated as fake.

Privacy and control
* The Community Threat Network opt-in is now offered as an explicit, unticked checkbox in the setup wizard, with a plain-English description of exactly what is shared. It stays off by default and can be changed any time in Settings → Advanced.
* New: « Behind a proxy or CDN » setting. Leave it on (the default) if your site is behind Cloudflare, a CDN or any reverse proxy. Turn it off if visitors reach your server directly, so forwarded IP headers — which a visitor can fake — are ignored in favour of the real connecting address.

Housekeeping
* The plugin now identifies itself and its version in its API requests.
* reCAPTCHA verification failures caused by a network error reaching Google are now recorded in the Threat Log instead of passing silently, and the fail-open behaviour can be changed with the ipsentry_recaptcha_fail_open filter.
* Removed two settings that were registered but no longer had any effect.
* Corrected the documented cache lifetime: results are cached between 5 minutes and 1 hour per IP, following the lifetime the API recommends.

1.13.0

Firewall
* The firewall now inspects large form submissions. Previously, if a request’s form fields totalled more than 8KB, every firewall rule except the user-agent check was skipped – so an attack in the URL or a form field went uninspected and unlogged if any other field on the page was large. Attacks hidden inside an oversized single field are now inspected too.
* Note: because these requests were never inspected before, a very long submission (a lengthy comment or contact-form message) that contains code-like text – backticks, $(...), or <script written in prose – may now be blocked where it previously slipped through. This is the same behaviour shorter submissions have always had.

Allow-listing now takes effect immediately
* Clicking Allow on a blocked visitor now unblocks them straight away. Previously only ordinary page views recovered; the visitor’s REST (wp-json) and XML-RPC requests kept being refused for up to an hour, which broke comment forms, block themes and app access for someone you had just allowed.
* Adding an IP to the allow-list on the Settings page now does the same. Previously it had no immediate effect at all, making the allow-list look broken.

Brute-force protection
* Fixed the risky-IP login limits not applying. Login protection was reading a cached verdict that nothing wrote any more, so an attacker on a VPN, proxy or Tor exit was given the relaxed limit for clean addresses instead of the stricter one, and no auto-blacklist followed.

Reporting
* The dashboard no longer counts monitored or flagged visitors as blocks (measured on real data, this removed a 13.6% over-count), and now correctly counts auto-blacklist and temporary lockouts, which were being missed.
* The hardening score now reflects the XML-RPC setting. It was reading an option the settings screen has not written since 1.10.0, so hardening XML-RPC never moved the score.
* Risk levels now match the bands the Predax API actually issues.
* Fingerprint events now respect the « event tracking » setting instead of being recorded regardless.
* Fixed a custom block-page title showing escaped characters (an apostrophe appearing as ').

Efficiency
* Predax Security and Predax Fraud Guard now share one cached verdict per visitor, so a site running both no longer spends two checks on the same person.
* Cached verdicts now follow the lifetime the API recommends (up to an hour) instead of a fixed five minutes, which significantly reduces how much of your allowance a busy site uses.
* The cache key now covers the whole request rather than the IP alone, so one visitor’s result can no longer be served to a different visitor behind the same network.

Housekeeping
* Uninstall now cleans up correctly on multisite networks (per-site tables and options were previously left behind) and removes leftover lookup locks.
* Added optional automation-detection scoring based on browser header consistency. It only scores and never blocks; enforcement is not enabled.
* New one-time notice confirming your first blocked threat, so a fresh install shows evidence it is working.
* Tested up to WordPress 7.1.

1.12.5

• Fix: hitting your plan’s DAILY check limit no longer reports it as the monthly limit. The notice used to say screening was paused « until your quota resets on the 1st » when it actually resumes at midnight UTC the same day – up to a month of wrong information at the moment it matters most. It now names the right limit and tells you the exact time screening resumes.
• Improved: fewer API checks are used for the same visitors. When several requests for one visitor arrive at the same time (a page load often makes several), the plugin now performs a single lookup and shares the result instead of one lookup per request. Busy sites will notice their daily allowance lasting longer.

1.12.4

• Fix: region blocking now saves « All of Africa », « All of Asia » and « All of the Americas » selections. Previously they were silently discarded on save – the checkbox reverted and no visitors from those regions were ever blocked, with no error shown.
• Fix: re-running the Setup Wizard and choosing « Monitor Only » now also switches off known-malicious IP blocking. Previously that one rule stayed on if a stricter preset had enabled it, so a preset promising to block nothing kept blocking.
• Fix: the « Blocked Today » / « This Week » dashboard widget no longer counts monitored or flagged visitors as blocks – it now reports only visitors who were actually blocked.
• Fix: the weekly protection widget now counts auto-blacklisted attackers and brute-force lockouts, which it previously listed as categories but could never actually count.

1.12.3

• New: an invitation to join the Community Threat Network now appears on your dashboard, with a one-click opt-in. Sites in the network warn each other, so an attacker stopped on another Predax site is already known to yours. It remains entirely opt-in and was previously easy to miss – it lived only as a toggle in Settings.
• Improved: clearer wording about exactly what is shared – the attacking IP address and the reason it was blocked, never visitor personal data and nothing about your site.

1.12.2

• Security: the firewall now runs on every request. It previously ran last, so any visitor the other rules had already judged skipped it entirely – including VPN visitors on the Recommended preset, where VPN is set to monitor. Attacks from those visitors were not inspected or logged.
• Security: the firewall is no longer skipped for an hour after a visitor’s first clean request. Visitor results are cached to keep your site fast; that cache described the visitor, not the request, so it was letting later attacks through uninspected.
• Security: the firewall now keeps working when the Predax API is unreachable. An outage previously disabled it, even though it runs entirely on your own site.

1.12.1

• Fix: VPN visitors were being blocked as « datacenter ». Because VPN servers live in datacenters, the datacenter rule ran first and caught them — so turning « Block VPN » off did nothing, and the Threat Log showed « datacenter » instead of « VPN ». VPN and proxy are now checked first, so your toggles work and the log names the real reason.
• Fix: visitors set to « monitor only » for VPN are no longer blocked when datacenter blocking is on.
• Fix: the dashboard’s Recent Blocks list showed « Monitored » for visitors who were actually blocked. Only locally-triggered blocks were recognised; blocks based on IP intelligence were mislabelled.
• Fix: sites in the Community Threat Network were reporting every visitor as having no VPN/proxy/Tor/datacenter signal, so shared intelligence was based on incomplete data.
• Fix: honeypot-triggered blocks were shown as « Monitored » on the dashboard.
• Fix: the [ipsentry_badge] shortcode counted only locally-triggered blocks, so most sites displayed zero.
• Improved: block page reference codes are now readable — « DATACENTER_BLOCK » instead of « DC_BLOCK », « FIREWALL_SQL_INJECTION » instead of « WAF_SQLI », and so on.

1.12.0

• Fix: verified search engines (Googlebot, Bingbot) are no longer blocked. On the Strict preset the datacenter rule was blocking them, which over time removes a site from search results.
• New: visitors blocked by a category rule can tell you they’re genuine. Reports appear on the Threat Log with full risk detail, and you can allow the IP in one click.
• New: allow any IP directly from the Threat Log.
• New: tell us why you’re deactivating, so we can fix it.

Older versions

The full history back to 1.0.0 is in changelog.txt in the plugin folder.