The gap: a botnet C2 IP hitting your login form used to only get caught by luck

If you've been running Predax Security or Fraud Guard for WooCommerce, you're used to VPN, proxy, Tor, and datacenter detection catching traffic that's trying to hide where it's coming from. That's useful, but it's a proxy signal — it tells you something about *how* the traffic is routed, not whether the specific IP address has actually done anything malicious.

There's a separate, more direct category of bad IP: one that's already confirmed, right now, to be an active botnet command-and-control server, or part of a network range that's been hijacked or compromised. These IPs aren't VPN exit nodes and they're not always in a datacenter range — they can look like perfectly ordinary residential or business IPs on paper. Before this release, an IP like that only got blocked if it happened to also push your overall risk score over the blocking threshold. If it didn't, it walked right through your login form, registration page, or checkout, no different from any other visitor.

This release closes that gap, and fixes two other real friction points at the same time: setting up either plugin used to mean leaving WordPress entirely to go create a predax.io account and paste a key back in, and once a plugin was blocking things, there wasn't a good way to actually see what it had blocked without digging into a settings page. Here's what changed.

A dedicated known-malicious IP category

Both Predax Security and Fraud Guard for WooCommerce now have a distinct blocking category for IPs that threat-intelligence feeds have confirmed are actively malicious — specifically, active botnet C2 infrastructure and hijacked or compromised network ranges. This runs independently of VPN/proxy/Tor/datacenter detection, so an IP that isn't tunneling through anything but is still a known bad actor gets caught on its own merits.

The customer-facing labels are deliberately neutral — you'll see something like "botnet C2" or "hijacked netblock" in your logs, not a named commercial threat feed. That's a simplification worth being upfront about: the underlying data comes from more than one intelligence source, and one of them has licensing terms that don't allow attributing blocks to it by name in customer-facing product output. The category itself, and what it catches, is real; the label is just deliberately generic rather than naming a specific vendor.

This is off by default on existing installs. That's a deliberate choice, not an oversight — a security plugin silently turning on a new blocking category on a site that's already live, without the admin doing anything, is exactly the kind of behavior that erodes trust in security software. You turn it on one of two ways: pick the Recommended or Strict preset in the setup wizard (both include it by default for new setups), or, if you've already got a key connected, there's a one-click "Enable" button that shows up on the dashboard. Either way, it's an explicit action, not something that happens to you.

Worth being clear about what this doesn't do: it's not a replacement for the existing risk-score threshold or the VPN/proxy/Tor/datacenter toggles, and it's not going to catch every attacker — it catches ones whose IP has shown up on an active-threat feed recently. Attackers rotating through fresh, unlisted infrastructure won't trip it. It's an additional layer, not a silver bullet.

Connecting the plugin no longer means leaving WordPress

Up until now, setting up either plugin meant a sequence that added real friction for anyone trying to get protection running quickly: install the plugin, open a new tab, go create an account on predax.io, verify your email, find the API key in your account settings, copy it, come back to WordPress, and paste it into a settings field. Miss a character or grab the wrong key and you get a cryptic auth error with no obvious next step.

The setup wizard in both plugins now has a "Connect with Predax" button that does all of that in one step, using OAuth — click it, authorize the connection, and the plugin comes back with an API key already linked. No account-creation tab, no key to copy, no paste step to get wrong. If you already have a Predax account, the same flow logs you into it rather than creating a duplicate. Manual key entry is still there for anyone who wants it — some admins reasonably prefer not to grant an OAuth connection and would rather paste a key they generated themselves — but it's no longer the only path, or the default one the wizard steers you toward.

The free tier underneath this hasn't changed: 5,000 IP checks a month, no credit card required to start. What's changed is that getting from "I installed this plugin" to "it's actually connected and running" is now realistically a one-minute task instead of a multi-tab detour. If you're evaluating either plugin for the first time, this is the fastest way to see it working — see predax.io/integrations/wordpress or predax.io/integrations/woocommerce for the current setup flow.

Seeing what's being blocked matters as much as blocking it

A security or fraud plugin that quietly blocks things in the background and never shows you what it's doing is hard to trust and hard to tune. This release adds two ways to actually see what's happening without digging through a full log.

Predax Security now ships a native WordPress dashboard widget — "Predax Protection This Week" — that appears on the main wp-admin Dashboard page itself, not tucked away inside the plugin's own settings. It shows a 7-day rollup of blocked threats broken down by category: VPN, proxy, Tor, datacenter, malicious, and a catch-all "other." If you're the kind of site owner who logs into wp-admin, glances at the dashboard, and moves on, this is now enough to tell you protection is actually doing something, without a single extra click.

Both plugins' full logs — the Threat Log in Security, the Events Log in Fraud Guard for WooCommerce — also got a reason filter. Previously these were a single scrolling list of every block, regardless of category, which gets unwieldy fast on a site fielding a steady stream of Tor and VPN traffic alongside the occasional malicious-IP hit. Now you can filter down to just one category at a time — pull up only the malicious-IP blocks to review a specific incident, or only the Tor blocks if you're deciding whether that category is worth keeping on for your audience.

Neither of these changes anything about blocking behavior. They're purely about visibility, on the theory that a plugin you can't observe is a plugin you'll eventually stop trusting or stop tuning correctly.

For WooCommerce store owners specifically: reliability and privacy

Fraud Guard for WooCommerce got two categories of work this release that are specific to running fraud screening on a live checkout, where a slow or wrong decision has direct revenue consequences.

On reliability: checkout fraud screening now runs behind a circuit breaker that fails open instantly the moment the Predax API is slow or unreachable, meaning your checkout keeps working normally rather than hanging or blocking a legitimate customer because of an API-side problem on our end. The request timeout was also cut from 8 seconds down to 3.5 seconds, tightening the worst case even before the circuit breaker would trip. The plugin's default posture has always been tag-only rather than blocking — flagged orders get marked for review, they don't get auto-rejected unless you explicitly turn that on — and this reliability work is built on the same philosophy: a fraud check should never become the reason a good customer's checkout fails.

Beyond the malicious-IP category above, the plugin's IP allow/deny lists now support both IPv4 and IPv6 CIDR ranges, and there's a chargeback-feedback option: when you flag an order as a chargeback, you can have that IP automatically added to your store's deny list going forward, turning a real loss into a concrete defensive action rather than just a data point in a log.

On privacy: customer emails stored in the Events Log are now masked by default — [email protected] shows up as bi***@example.com in the log itself. The underlying WooCommerce order still has the full email, because that's needed for legitimate business purposes like order fulfillment and support, but the security log doesn't need to retain a plaintext copy of every customer's email indefinitely just because it screened that order once. Retention on the log is configurable, so old entries — masked or not — age out rather than accumulating forever.

Getting started

Both plugins are free and available now: Predax Security for WordPress and Fraud Guard for WooCommerce. If you're setting up either for the first time, use the "Connect with Predax" button in the setup wizard rather than hunting for a manual API key — it gets you to a working, connected plugin faster, and you can always switch to a manually-entered key later if you want to.

If you're already running either plugin, none of this changes your existing configuration on its own — the malicious-IP category specifically stays off until you turn it on, either via a wizard preset on a fresh install or the one-click dashboard button on an existing one. A reasonable first move on an existing site: check your dashboard (Security) or Events Log (WooCommerce) for the new reason filter, get a sense of what's currently being blocked and in what proportion, and then decide whether adding known-malicious blocking on top of that makes sense for your traffic. The free tier is 5,000 checks a month with no credit card required, and pricing covers what higher-volume plans look like if you outgrow that.