What Is the WhoKnew Intelligence™ Network?

A WordPress site running alone sees exactly one thing: the attacks aimed at it. If a bot scans a login page at 3 a.m. and moves on, that site’s owner has no way of knowing whether the same IP hit ten thousand other sites that same night, or whether it was a one-off fluke. Every WordPress install, by default, defends itself in total isolation — which means every WordPress install also rediscovers the same threats from scratch, over and over, site by site, with no memory of what any other site already learned.

WhoKnew Intelligence™ closes that gap. It’s the shared threat network underneath WhoKnew Shield™ Pro — a blocklist that every participating site both draws from and contributes to. Here’s exactly how it works: where the list comes from, how a new IP actually gets added, why that takes more than one report, and what a site owner actually gets from plugging into it.

What a Shared Blocklist Actually Is

A blocklist, at its simplest, is a list of IP addresses a system refuses to let through — checked at the firewall, the WAF, or the application layer before a request ever reaches the site itself. Security researchers generally group blocklists into a few categories: public blocklists maintained by established threat intelligence organizations, commercial feeds sold by security vendors, and crowd-sourced lists built from real detections reported by a community of users. WhoKnew Intelligence™ is the third kind — closer in spirit to community-driven projects like CrowdSec than to a single vendor’s proprietary feed, built on an established industry feeds as a starting baseline.

Why One Site Alone Can’t See the Pattern

The idea that a crowd sees more than any single participant isn’t unique to WordPress security — it’s the entire premise behind collaborative threat intelligence as a category. CrowdSec, one of the better-known examples of this model, describes it as “the network effect of cyber threat intelligence” — a single honeypot or a single protected site can never generate the volume or diversity of real attack data that thousands of independently operated, genuinely targeted sites can produce together. A honeypot only attracts opportunistic, low-effort attackers. A real WordPress site with real traffic attracts the attackers who actually matter.

Scraper Trap™ — Shield’s honeypot layer — catches bots on individual sites constantly. Without a shared network, that catch data dies on the site that caught it. With one, a bot that scrapes a florist’s contact page in Ohio and a law firm’s contact page in Texas within the same week gets recognized as the same threat, and every other participating site gets the benefit of that recognition before the bot ever reaches them.

A scraping operation that rotates through residential proxies to hit ten thousand WordPress sites over a month looks, from any single site’s perspective, like an isolated, forgettable incident. From the network’s perspective, it’s the same operation showing up ten thousand times — and the tenth time is a very different signal than the first.

How an IP Actually Gets Added to the Network

An IP doesn’t reach the WhoKnew Intelligence™ blocklist because one site reported it once. It has to clear a threshold first.

That threshold is what keeps the network reliable rather than noisy. Adding an IP to a shared list after a single report is the failure mode that makes cheaply built blocklists untrustworthy — one misconfigured trap or one overzealous false positive on a single site would otherwise be enough to get an innocent visitor blocked everywhere.

Why It Takes More Than One Report

IP addresses get reassigned constantly. An address flagged for scraping today can belong to a completely different, entirely innocent site or residential user next month once an ISP hands it out again. Mature threat intelligence networks treat this as a routine problem — CrowdSec, for instance, reports an average daily IP rotation of roughly 5% across its own network specifically to keep pace with dynamic reassignment, removing addresses that are no longer actually malicious as aggressively as it adds new ones.

Requiring multiple independent confirmations before an IP joins the list is the direct countermeasure. A bot has to actually hit several unrelated, independently operated sites before the network acts on it — which also happens to be a reasonable proxy for “this is a real, broadly operating threat” rather than one site’s misconfigured trap.

What Counts as a Report — and What Doesn’t

Not every blocked visitor becomes a report. Scraper Trap™ is built specifically to avoid catching legitimate crawlers — search engine bots that respect robots.txt, accessibility tools, and ordinary human visitors who would never follow a honeypot link in the first place don’t trigger it. Only automated behavior that ignores the normal rules of a site — following invisible links, hitting paths no navigation points to, requesting pages at a speed no human browser session could match — generates a report at all. A deeper breakdown of how the trap itself distinguishes real bots from real visitors lives in the dedicated Scraper Trap™ explainer.

What Happens When You’re Wrongly Blocked

No confirmation threshold makes a network immune to mistakes entirely — shared IP addresses, VPN exit nodes, and CGNAT ranges used by ISPs can occasionally put a genuinely innocent visitor behind the same address a bot used previously. WhoKnew Intelligence™ has a direct appeal path for exactly this situation: a public removal request form where a flagged IP owner can contest the listing. Mature security teams evaluate blocklists by how well they handle this tradeoff between coverage and false positives, not by whether a false positive can theoretically ever occur.

How to Actually Use the Network

The blocklist itself is free to download and use, whether or not you run WhoKnew Shield™ at all. It’s published through a public API with no license key required.

All three endpoints cache for one hour on the blocklist and five minutes on the stats endpoint, which is enough to keep the list current without every firewall on the network hammering the same server every minute. Point a fail2ban configuration or a WAF’s custom IP list feature at the .txt endpoint and refresh it daily; pull the .json version into a script if you need the structured metadata alongside the raw addresses.

Inside WhoKnew Shield™ Pro specifically, the network runs automatically — no separate setup step beyond having Pro active and WhoKnew Intelligence™ enabled in plugin settings, which is also where it can be turned off entirely if a site owner prefers not to participate. Disabling it removes both contribution and access to the shared list for that site; it doesn’t affect any other participating site.

What Data Actually Leaves Your Site

Contributing to a shared threat network raises a fair question: what exactly does your site hand over when it reports a bad actor? When Scraper Trap™ catches a bot and that catch becomes a network report, the only thing that travels with it is the flagged IP address itself, tied to an anonymous submitting license or domain reference used for network accounting. No visitor names, no email addresses, no site URLs, no browsing history, and no personally identifiable information leaves your server as part of that report — that’s the entire dataset a report contains.

That narrow scope also keeps the network simple to trust. A blocklist that needed rich context — user agents, referrers, session behavior — to function would be a different, more sensitive kind of product to run on your site. An IP address on its own is enough to answer the one question the network exists to answer: has this address behaved like a bot before.

How This Fits Alongside Wordfence or Sucuri

WhoKnew Intelligence™ isn’t a replacement for a full WordPress firewall like Wordfence or Sucuri, and running Shield™ Pro isn’t a reason to skip one. Firewalls like those inspect a much broader range of attack types — SQL injection payloads, malicious file uploads, brute-force login patterns, known exploit signatures — and operate at a different layer of the request than an IP blocklist does. WhoKnew Intelligence™ solves a narrower, specific problem: recognizing an address that’s already demonstrated automated, hostile behavior on other sites, before it has the chance to demonstrate anything on yours. A firewall and a shared blocklist answer different questions — “is this specific request malicious” versus “has this specific address behaved badly before” — and a site benefits from both rather than treating either as a substitute for the other.

In practice, the two integrate cleanly rather than compete: the blocklist download endpoints exist specifically so a site can feed WhoKnew Intelligence™ data into a firewall’s own custom rules, turning network-level reputation into one more signal an existing security stack already checks.

Does This Slow Down Your Site?

Checking a visitor’s IP against a list of 15 million addresses sounds like it should be slow, and for a naive implementation it would be. In practice, blocklist lookups run against an indexed structure built for fast matching — closer to a database lookup than a line-by-line scan — so the check adds negligible overhead per request, well under the latency a visitor would ever notice. Inside Shield™ Pro, this happens automatically at the point a request comes in, before WordPress itself finishes loading, so a blocked bot never reaches the parts of the site that are actually expensive to render.

The public API endpoints are a separate concern from that in-plugin check — those exist for site owners who want to pull the list into their own firewall or fail2ban setup rather than relying on Shield to do the matching. The one-hour cache on the blocklist endpoint means a script hitting it once an hour, rather than on every single request, is enough to stay current without adding meaningful load to either side.

What Changes as More Sites Join

WhoKnew Intelligence™ today runs on an established industry feed as its baseline, with real Shield™ Pro detections layered on top and growing every day a new site activates the network. That balance shifts over time. More participating sites means more independent reports crossing the confirmation threshold faster, which means a larger share of the list reflects live, self-sourced detection rather than the starting baseline. It also gives the threshold itself room to move past a fixed number — a network with a hundred sites and a network with a hundred thousand don’t need the same confirmation math, and that math is built to keep pace with the network’s actual size rather than stay frozen at whatever number fit on day one.

Who knew the bot hitting your contact page tonight had already been caught somewhere else last week — and that the only reason your site never saw it was that nobody had built the network yet.